SimpleFeatureService: yet another attempt to simplify vector data dissemination – Part I
In the current web gis world the most common standard protocol to disseminate vector data is the OGC Web Feature Service (WFS). While the protocol is fine, it has a number of shortcomings if we focus on the simple features dissemination case:
- the protocol is complex, writing a client is often hard and error prone, same goes for implementing a new WFS server
- the axis order issue makes it difficult, even today, to know what the axis order of the data returned by a WFS is
- usage of GML implies there are many ways to present the same information or the same geometry (think polygon vs surfaces, or the issue that sometime arise with the feature built in attributes, such as name and location, with the ones that the application wants to publish)
In SOA architectures it is common to have different pieces of the overall system written in different languages, and sometimes there is a need for some part to exchange simple vector data information: we were looking for a quick to implement protocol that would get the job done without the extra complications of WFS (btw, we’re not throwing away standards, in fact GeoServer WFS would be used to cascade the simpler protocol into the more complex, but standard compliant, WFS 1.1).
A quick research showed that GeoJSON would have been a very good candidate for data transport, since there are ready made parsers and encoders for the most common languages. The existing Mapfish data query protocol also seemed to fit the bill quite nicely, however we found some limitations that make it hard to use the protocol as a source of data to be cascaded via WFS:
- there is no entry point that lists all the available layers
- there is no way to know in advance what attributes will be returned and what is the spatial reference system of the geometries, nor is the axis order known (we want that to be explicit, just to make sure we avoid the same issues we’re seeing in WFS)
- there is no way to quickly get just the bounds and count of the features satisfying a certain filter
- there is no recognized way to eventually transport vendor specific parameters (in our case, a multidimensional query for OLAP systems)
- the pure restful-ness of the protocol does not allow to pass over many parameters
What we did was to extend the protocol a bit to support the above requirements, making it into a very simple OGC like service, and making concessions to the usage of POST requests to gather data.
Well, we can already hear the restful purists yelling about the usage of POST requests to get data. We’re aware that it would have been possible to handle that, but each solution would have had drawbacks:
- storing the query as a resource would have required to add urls to handle such resources, and some way to expire them (can’t trust the client to orderly go and remove them manually)
- providing a link back to the full query would have implied the client can publish resource and that the server can link back to them, both cases are not always met in practice
The focus of this protocol is implementation simplicity, so that a diversity of implementors in different languages can quickly get a simple feature service up and running, so we believe that in this case pragmatism needs to have the upper hand over religion. If it’s possible to implement the service quickly and without ambiguities we basically reached our goal, any other improvement can be of interest provided it does not hamper this primary objective.
A PDF document describing the current layout of the simple feature service procotol is available. There are a few questions that we feel are still open:
- the layout of the urls could probably follow a more hierarchical structure
- the data type conventions could be fleshed out in more detail (thinking about date/time/timestamp for example)
- the feature attributes is an unordered set, however cascading by WFS will result in some order being chosen. Wondering if the order should be established at the simple feature service protocol directly (by using an array of attributes in the describe layer output)
- the documents may be linking each other (this would be make the service crawlable by search engines, assuming that is even a goal and not, on the contrary, an undesirable feature)
- the capabilities could be turned into a simple list of names and we could have the describe resource provide also the spatial reference system and bounds informations
Let us know what you think!
