In my previous article, I wrote about the Open Geospatial Consortium (OGC) Web Processing Service (WPS) standard and how it can be used to enable different geographic data processing capabilities to work together. In this article, I’m going to discuss a second example that has been under development by Esri for a few years, but was just released as a published specification. At this summer’s International User Conference, Jack Dangermond announced that Esri would be publishing a REST API as a new standard. A couple of weeks ago, Esri made good on that promise and released the GeoServices REST Specification.
What the heck is the GeoServices REST Specification?
Rather than an alternative to WPS, one might actually see this as an alternative to the WMS, WCS, WFS, WPS and Catalog standards while also providing services for which there are no existing OGC standards, such as geocoding. The REST-based specification supports JSON, HTML and KMZ responses, with JSON being the default format. The full list of service categories includes:
- Catalog Service – a list of available services.
- Map Service – make maps as well as query, ID and other map functions; much like WMS, though with more functionality.
- Geocode Service – turn addresses, intersections and place names into map coordinates; also includes reverse geocoding.
- Geoprocessing Service – you can probably guess that this is my favorite service; both synchronous and asynchronous execution of tasks; this is the service that most closely resembles WPS.
- Geometry Service – utility functions for commonly used vector geometry operations such as reprojection, simplify and densify, buffer, area/length calculation, label points for polygons, distance calculation, generalize, trim/extend, convex hull, cut, difference, intersect, union and reshape; these could also be implemented as WPS services (or through the Geoprocessing Service) but these are provided as a lighter weight, easy-to-use set of utilities; there’s a lot of overlap here with JTS and NTS and one could imagine a rapid implementation of this service using these toolkits plus a projection engine.
- Image Service – provide access to existing imagery, in particular raster catalogs and mosaicked images; this service also includes local and neighborhood transformations of the imagery, such as recolor, hillshade, slope, aspect, NDVI, statistics, stretch and identify functions.
- Feature Service – provides functions for querying and editing vector features stored in a geodatabase; the closest OGC equivalent is WFS.
What will this mean?
On its own, the GeoServices REST spec does not mean much. It will need a community of developers that are willing implement the specification. That will mean building back-end server processes that will respond to requests made according to the specification. The open question is whether or not developers will embrace the standard and will it catch on in the marketplace? That’s obviously impossible to answer right now, but some of the potential can be seen in Brian Flood‘s work on the Arc2Cloud product. Brian and his brother got to be feeling pretty smug at this point. By implementing many parts of the ArcGIS Server REST API, his Arc2Cloud product already supports the majority of the GeoServices REST specification with the server processes running in the Google App Engine cloud computing infrastructure. This is a very compelling concept – build geoprocessing services that operate against cloud infrastructure but enable many, many people to use them by doing so on top of an established standard.
For Esri, this is a risky move. Similar to the risks ERDAS faces by embracing WPS, Esri is creating a specification that, if broadly adopted, will make it easier for some people to not use their flagship ArcGIS Server product. On the other hand, by demonstrating leadership in the geoprocessing market, they will both encourage the growth of that market and their broad product line puts them in a good position to capitalize on the larger marketplace. I see this as a smart move by a company that feels sufficiently self-confident in its spatial analysis, geoprocessing and data management capabilities that it can invite both partners and competitors to the table.
There has also been some early criticism of the GeoServices specification. Some punters have remarked that this is not really an open standard since it hasn’t been submitted to an independent standards organization and is not open for public comment and changes. Browsing the specification, one my colleagues also remarked on the extensive use of the “esri” prefix in things like enumerations. That’s something that we would generally not see in an open standard and suggests that this isn’t really intended as something to be used outside the Esri ecosystem.
On the other hand, the new specification is being made available under the Open Web Foundation agreement, which should make the spec free of copyright and patent claims as well as enable others to revise, share and implement as they see fit. Further, there are many paths for specifications and standards as they evolve. As the OGC has amply shown, submission to a standards body does not guarantee usefulness. While the OGC has several standards that are in broad use (Simple Features, WPS, WMS, WFS, KML and WCS), it has also got a bunch of “standards” that have been submitted for narrow, commercial purposes and have failed to gain broad market support. As the longevity of the shapefile has demonstrated, open publication of protocols can have a significant positive impact on interoperability, even if it’s not managed by a standards body. Further, as Google showed with KML, commercial shepherding of a protocol for a few years can be a precursor to later submission to a standards organization.
- Esri GeoServices REST Specification web site: http://www.esri.com/apps/products/geoservices/rest2010/