17 Oct 2008 - WMS, WFS, and Community Schemas

For those that follow this blog, the terms WFS and WMS are likely well known.  For those who do not, let’s do a brief refresher.  WMS stands for Web Map Service, which is an OGC/ISO specification that defines an interface by which a client can request a map as a graphical presentation of geographic information.  The interface allows the client to specify the spatial extent/scale, projection and appearance of the map.  WFS stands for Web Feature Service, which is a complementary specification from OGC/ISO that defines an interface for requesting geographic data.  The interface allows the client to specify the spatial extent (or more complex spatial constraints), the coordinate system, and the particular feature types (e.g. road, railway) that are desired.  Geographic data is returned to the client in GML (ISO 19136).

The original intent of these specifications was to enable “interoperability” and to support data integration.  In the WMS case, this meant that irrespective of the underlying data store, a client could request maps from multiple WMS and overlay them and get a “sensible” result.  In the WFS case, this was to mean that a client could request data from multiple WFS and integrate that data.

Unfortunately, in the majority of cases, this is not as easy as one might expect.  Popular open source WFS software like GeoServer, as one example, only very partially support the idea that the exposed schema(s) (via GetCapabilities and DescribeFeatureType operations) may be different from the underlying schema(s) in the data store.   This makes it more or less impossible to do any sort of data integration since there is no way to support a shared or “community” schema.  This is starting to be addressed in the Community Branch of the GeoServer development, but I found it rather shocking that, approaching 10 years after the initial discussions, this is not a requirement for all WFS.  In some ways one could say that this is “the point” of a WFS.

The lack of so-called “community schema” support also explains the common occurrence of an architecture where a WMS and WFS are backed by the same shared data store.  While some arguments can be made in favour of performance this is, in many ways, a curious arrangement since there is no visibility as to how the “features” (objects) exposed by the WFS are styled for presentation in the WMS.  It is all black magic.

An architecturally more satisfying approach would be to have the WMS get features from the WFS, apply styling rules, and then generate the requested map.  This approach offers far greater flexibility, and does not hide the feature model behind the WMS.  Moreover, the WMS can, in this case, obtain data from many WFS, without any knowledge of the their underlying data store schemas, and they can do this concurrently.

Such an arrangement is allowed in the WMS specification via the strangely named “Component WMS”, although I would prefer to think of this as a Feature Portrayal Service.  This architectural understanding seems a long time in coming and, even today, most implementations are far from maturity.

The bottom line in all of this is that we are still some ways from getting the architecture right for sharing geospatial information.  The WFS and WMS work to date has helped, but there is clearly still a ways to go.  Look at your own installations and start thinking seriously about decoupling the WMS and WFS, and making moves to truly handle the schema mapping issues.   It will only hurt when you laugh.