Evolution of Interfaces to Spatial Data
While we like to talk about the unending creation of spatial formats (no one format fits every need), I find it interesting that software interfaces designed to hide differences between formats are proliferating too. While the details are most interesting to developers, the end result — making it easier to combine data or get it to the application you need — is more broadly relevant. I’d like to discuss a few of these and offer some thoughts about their ongoing evolution.
OGC Simple Features or SQL/MM-3
Standard interfaces for relational databases have been around for a long time. The most common of these are SQL (the standard language for querying and interacting with relational data) and ODBC (a software interface that allows programs to connect any database, regardless of vendor), although there are certainly others. OGC’s Simple Features for SQL and ISO’s related SQL/MM-3 extend SQL with standard ways to interact with spatial data in databases. In theory, you could put all this together to create an application that talks to any spatial database (without knowing the details of each), and these standards get you very close, but in practice there are variations between systems that matter.
Feature Data Objects
FDO, designed and later open sourced by Autodesk, is a software interface that allows read/query/edit access to arbitrary spatial formats. Similar in spirit to ODBC, applications can integrate with FDO to get access to any supported format, and plugins (called providers) can be developed to support new formats. A key difference between FDO and the SQL approaches above is the focus on spatial data and GIS use cases: data can come from files or databases, and the key operations are things like “query within an envelope” or “edit this feature”.
OGC WFS (and other related web services)
WFS and WFS-T provide read/query/edit access to vector features over the web; they are part of a large family of related web service standards. WFS clients are shielded not only from the underlying data format (which the server typically converts into GML), but many of the other details as well; the data can come from any conforming server on the network.
RESTful Web Services
One of the critiques of WFS and related standards is that they are RPC-based and don’t follow the REST architecture. While I won’t go into the details of SOAP (RPC over XML) vs. REST (e.g., see here), I do observe that many of the GIS vendors have server products that expose both kinds of APIs, and that there is clear demand* for RESTful web services to access geospatial data.
These technologies represent a trend towards simpler, more distributed, and more interoperable data sharing. Each can play a role in making it easier to get spatial data to where it’s needed. Our product, FME, works with each: We leverage SQL standards when talking to databases, read data via FDO, act as an FDO provider to expose hundreds of formats to applications like AutoCAD Map, can consume or serve WFS, and FME Server has its own REST API. (Note that we haven’t tackled WFS-T or the live editing aspects of FDO; these are outside our focus, at least for now.)
How are you leveraging standards or web services to get access to spatial data?
* For those following the second link: Yes, we love XML and are excited about INSPIRE, but also agree not every tool is right for every job.
