Simple Feature or Full Feature Specification for OGC?

The issue of how to write-to and read-from geographic databases has been around for quite some time. Esri shapefiles were a runaway success partly because of their open specification. As we moved onto spatial databases, the Open Geospatial Consortium (OGC) offered the simple feature specification (SFS) that all the players could read to or write from. This came in especially handy for consuming web mapping services (those and many other specifications have grown since). But it gets trickier when it comes to reading from and writing to spatial databases generically. By that I mean not from the native application but from others', like with shape files.

This came to a head recently with the expectation set up at Esri UC2011, where rel. 10.1 promised direct spatial database access. James Fee has bird-dogged this issue from a business perspective, to be able to write directly to any spatial database as a geodata facilitator at WeoGeo. SAFE's Transformers, to name but one, allow all manner of wizardry that will never go away in terms of maintaining data. But once clean and healthy, wouldn't it be great to write spatial data directly anywhere? Let me give you Andrew's view from a standards and metadata perspective.

The nub of the issue is really OGC's SFS versus, say, Esri geodatabase (GDB) full feature specification (FFS) if you will. That is really a push-me pull-you that has been around for a while too, as anyone involved with OGC will attest to. It's easy enough for Esri to allow non-Esri access to ArcGIS Server (AGS) services, as for example the Geoportal or arcgis.com - that's the pull-you part. Esri's File GDB API allows to write SFS directly, but you still need Esri tools to write to the full GDB - that is the push-me part. Breaking out the SFS from the GDB may not be practical from either perspective, business (Esri will protect its i.p. like anyone else) or technical (if OGC offered a FFS, then which one?). For another perspective see OSGeo's FDO (feature data object). And speaking of perspectives, I will close with an anecdote from my Esri days as petroleum industry manager.

Two competing standards for the pipeline industry emerged in the new millennium. Pipeline Open Data Standard (PODS) came from a long heritage of event-driven database technology, where data were managed from a DBA's perspective. As they were not aligned to any technology or standard except SQL and SFS, they were also vendor neutral and used by every GIS vendor. ArcGIS Pipeline Data Model (APDM) as its name indicates came more recently from an Esri business partner, who focused on feature-driven modeling of pipelines in the geodatabase. After another kind of push-me pull-you - like wagons that jostle back-and-forth as a train leaves the yard or the station - users and vendors from both camps eventually participated to the extent possible for each.

As I said elsewhere, this is all about horses for courses - some tools work better for some people than others - we each must pick out not only our own horse for each race course, but also our team to be in the winners' circle...

click on image to enlarge

Addendum: a comment in Bill Dollins' blogpost cited by James Fee pulls out a crucial clarification on this Esri blog; go to Scott Morehouse's reply to: Is the Spatial Database Server a Replacement for SDE?

Update: for a fuller treatment of the subject go to Safe Software 27 October blog on same