God REST Ye Merry Polygons

Since REST is all the rage these days, it must be about time to ask what it means for GIS. A lot of the striving middle class of programmers believes that REST is about not using SOAP. Questions of hygiene aside, it's certainly about a lot more than that. Is GIS ready for REST interfaces that are more than warmed-over POST interfaces?

REpresentational

REST is about exchanging representations of data. You've got to speak a common language. Here, surprisingly, GIS is in good shape. The Open Geospatial Consortium (OGC) guys have had a good amount of luck getting some useful standards into widespread use. It's true that WMS and GML are pretty big nasty specs, but they have real traction with a lot of vendors. WMS was turned on its head by Google's tiling, but the open source community[*] is back with a tiling idea. Google launched KML on an unsuspecting universe, but if you grok GML you can definitely grok KML. And we can even thank Big Oil for funding the only sensible world-wide collection of projection systems, the erstwhile EPSG database. GIS data can be transported around via XML and everyone can agree on what it means. Good deal.

State Transfer

Okay, here OGC gets less important. OGC talks about transactional feature operations in their Web Features Service (WFS) spec. It seems like people are slowly supporting this spec, but it is firmly in the older school of handling transaction and data transfer in an RPC-style, rather than in a resource-focused style. Of course most heavy lifting is still done with your choice of GDAL and OGR drivers, spatial database extensions, and CAD & GIS packages operating on files. State Transfer in the public standards-based GIS world (where REST really starts to achieve critical mass) is still all about the read-only flow of data from publishers to browsers.

The exception to all of this, and arguably the only end-user publishing game that matters, is Google Maps/Earth world, where users can post data using GeoRSS and KML. Real world resources (at random URIs) can be tagged with KML and found by Google. So for actually sharing data, not just pictures, KML is the name of the game.

So What About Enterprise GIS Data?

Indeed. Companies are less interested in the exact GPS locations of random jogger X's morning workout routine but in having a cohesive architecture for all their money-producing geolocated data, like oil wells, supermarkets and garbage trucks. Just becaues those resources have lat/longs doesn't mean that GIS should suddenly be the center of the universe. Why do I have to use KML for resources that probably have extremely rich alternate representations already? And what URLs do I give them? On the Internet, everything is usually an http:// or an ftp:// away -- there are only so many protocols in common use. But on an enterprise network there are RDBMS servers, file shares, SDE, WMS, random shared-process based middleware, and so on. Do these get their own protocols? To (finally) get to the topic this article's title suggets: what does a polygon's URL look like? Does the HTTP-centric REST even matter in a world of non-HTTP protocols -- protocols which are largely stateFUL, note stateLESS? Questions I will be grappling with over the coming articles. Stay tuned.

[*] This article originally stated that tiling was an OGC effort, which is not correct. A poster pointed out that the tiling effort I referenced was not OGC. I suspect OGC will not be far behind.