Creating a GIS Service Oriented Architecture Part II

In our last SOA episode, we talked about using web services, PostgreSQL and PostGIS to create a free, robust, SOA for the enterprise. Complex GIS questions can be answered and the results distributed to anything that understands WSDL and SOAP - which is just about everything post-Cobol.

The next logical question is: But what of the map? How can we incorporate map images and/or topological features into our SOA?

Fortunately the good folks at the Open Geospatial Consortium have already tackled this problem for us. What is the OGC?

The Open Geospatial Consortium, Inc. (OGC) is a non-profit, international, voluntary consensus standards organization that is leading the development of standards for geospatial and location based services. Through our member-driven consensus programs, OGC works with government, private industry, and academia to create open and extensible software application programming interfaces for geographic information systems (GIS) and other mainstream technologies.
The backbone of a SOA is open standards. An open standard is just that - it’s a publicly available and implementable standard. By having such a standard, disparate software and operating systems can talk with each other. Web services are so useful because they communicate via open standards, so anything can use them.

OGC has created standards for a number of things (you can see the whole list here), but the standards we are most interested in are:

WMS: Web Map Service, this is a specification for sharing geospatial information as images. Specifications for the image are passed by extended URL and includes items such as extent, layers, etc. The key thing to remember here is you are serving up an image (GIF, PNG, etc.). This allows you the maximum amount of flexibility in clients (almost anything can render an image), but as a static image there are natural limits as to what you can do with it.

WFS: Web Feature Service, this is a specification for sharing geospatial information as features. These features are passed in Geography Markup Language, or GML, which is essentially XML. Of course, the client here would need to be rather sophisticated, as it must process the GML and then render a vector or bitmap image on it’s own, but you can do pretty much anything with it - it’s more or less like getting features from a shape file or SDE layer. There’s also WFS-T, which is essentially a transactional WFS, meaning users can edit the data.

By using either WMS and WFS servers, we can add maps to our SOA. You can also mix and match map layers from different WMS and WFS servers in the same map document. The NC One Map project is a good example of this, combining WMS servers from all over the state, running on both ArcIMS and MapServer platforms.

In fact (dons his swami hat), I’d go so far as to say WMS and WFS will soon be the de facto standard for geospatial information sharing both internally and externally, replacing things like file shares and SDE servers. SDE is still (IMO) king of the hill for workflow editing/versioning type operations, but for general data sharing I think it’s too slow, too expensive, and too proprietary.

I’m still toying with different WMS and WFS servers to see which I like best. As of ArcIMS 9.1 it has WFS 1.0 capabilities along with WMS, but I don’t think I want to build my SOA around software that will randomly flake out on me. MapServer can act as a WFS or WMS server, but only in CGI mode. I’m looking at a couple of other FOSS packages now. With any luck, I’ll be able to recommend something and give some examples of a WMS/WFS implementation next month.