As you may have gathered from our recent newsletter article and other announcements about the CommonSpace project we’ve been developing in Philadelphia, we are in the middle of redesigning the geoprocessing engine that underpins our DecisionTree product. The new engine, code-named “Trellis”, is leveraging our experience implementing high performance raster processing operations. We are taking the lessons we learned with DecisionTree – distributed and parallel processing, binary messaging, caching, pyramiding, etc. – to create a more generic processing framework that will support a broader array of geoprocessing operations than was the case for the original single-purpose design created for the DecisionTree application.
We’ll unveil more details of the Trellis work as it evolves over the next few months, but as part of our design research, we’ve been looking at a number of the existing technologies related to server-based geoprocessing. This first article will focus on the Open Geospatial Consortium (OGC) Web Processing Standard (WPS).
WPS is one of an alphabet soup of geographic data and mapping standards overseen by a non-profit standards organization called the Open Geospatial Consortium (OGC). It’s a particularly interesting one for Azavea because it is concerned with making geographic data processing available across a network – essentially enabling us to move geo-computation and spatial analysis from a desktop GIS to the server and enabling this type of analysis to be provided as a service over the web or even in a mobile application. We think that this is a really important capability for two reasons: a) it will allow sophisticated analysis that has previously required a GIS specialist and complex software to be made available in simple applications on the Internet; b) we think this will result in faster, more responsive applications that can serve more people at lower cost.
OGC standards like WPS have developed over the course of many years and have arisen in order to support interoperability across diverse platforms. The OGC standards that Azavea has found most useful for its web and mobile applications are of two basic types: services the return some kind of geographic data; and formats for organizing and transporting that data across a network.
- WMS and WMTS (web map service and web map tile service) – service that provides map images for display in a web browser
- WFS (web feature service) – service to request and filter vector feature data in a geographic database
- WCS (web coverage standard) – service that provides raster data (aerial and satellite imagery, for example)
- GML (geography markup language) – this is an XML protocol for encoding geographic data
- KML (keyhole markup language) – developed by Keyhole and later purchased by Google as part of the software that would become GoogleEarth, KML was submitted to the OGC after it had undergone a fair amount of development; it does not fit neatly into the the other standards, but it’s broadly used for combining geographic data with styling
- SLD (styled layer descriptor) – a way to describe how to apply color and other styling on a map
What the heck is WPS?
So if WMS is for getting map images, and WFS and WCS are for requesting vector and raster data, and data can be transferred using KML and GML and styled using SLD, that’s a lot of what is done in the web map mapping world. What do we need WPS for? WPS provides a way to request transformations of existing geographic data. While much of contemporary web mapping remains a matter of simply displaying data on a base map and asking some basic questions about that data, the utility of geoographic analysis goes beyond display of information on a map. For example:
- in a flood scenario, we might want to know which properties are located within 100 meters of a flood plain boundary
- to find the perfect site for a school, we might want to consider several geographic maps layers, apply weights to them and generate a heat map
- for crime analysis, we might want to create a density map based on crime locations
In each of these cases, we need to transform one or more geographic data sets. To answer the first question, for example, we would need to buffer the flood plain polygons by 100 meters to create a new layer and then select records that fall within the new polygon. For the second scenario, we need to read each of the relevant map layers, convert them to a common format and scale, apply weights and then create and apply colors to a map of the results. WPS is a standard that supports requests for these types of geographic data transformations (processing) in a common way.
Like many of the OGC services standards, WPS is conceptually simple. It supports only three functions:
- GetCapabilities – returns information about the available processing features
- DescribeProcess – returns metadata specific to each available processing function
- Execute - runs a process based in a series of inputs
It’s important to note that WPS does not actually do anything. Like other OGC services, it is simply a lingua franca for asking for work to be done. if you host a WPS service, you still have to have software that executes the processing tasks. But WPS defines a common protocol for making requests for almost any kind of geoprocessing task.
Who’s Using WPS?
Unlike WMS, WFS and WCS and a few other standards, WPS is a relatively new standard that was only finalized in late 2007. There are not a lot of examples yet, but the reference implementation is a WPS server and sample clients being developed by 52° North, a non-profit based in Germany. The software project is being led by Bastian Schaeffer and Theodor Foerster and is a Java-based implementation that is available under an open source license. The project has an ambitious roadmap and a rapidly growing community. There is also ongoing work to create a connector to the geoprocessing capabilities in Esri’s ArcGIS Server as well as distributed (or “grid”) computing.
A second open source implementation is PyWPS, created for people using Python. It’s primary purpose is to make GRASS-based processing available to web clients.
In 2009, ERDAS released its own WPS-based web geoprocessing service. ERDAS refers to its WPS implementation as an internet Spatial Modeling Service (iSMS). The WPS interface supports access to the IMAGINE Spatial Modeling Engine by making calls over the internet. The capabilities are integrated into the ERDAS APOLLO server product line under the APOLLO Professional package. And, of course, ERDAS has enabled its client technology, the IMAGINE and TITAN products, to consume WPS-compliant services.
What’s the point?
So why is WPS important? As I mentioned above, like most information technology standards, the purpose of WPS is interoperability. If a standard becomes broadly adopted in many software packages, it becomes easier to mix-and-match components for a particular purpose. By enabling their APOLLO server to speak WPS, ERDAS is enabling any software that can make WPS requests to use the server, even if they are not ERDAS products. So I can use the uDig WPS plugin and make requests to spatial models defined and run in an ERDAS APOLLO server and display the results in uDig. For a commercial company like ERDAS, this is a double-edged sword. By supporting WPS, they are also saying that you don’t need to buy an ERDAS client software package in order to use an APOLLO server. But, by the same token, it also means that now many more people will be able to make requests to APOLLO servers, and this will grow the ERDAS ecosystem and may result in higher sales of APOLLO and IMAGINE licenses.
In a second article, I’ll focus on an even newer standard just published by Esri, the GeoServices REST API specification.
Resources
