What can WPS do?
WPS specifies a generic mechanism that can be used to describe and web-enable any sort of geospatial algorithm, or "process". Each implementation of WPS describes each of the processes that it offers, as well as their associated inputs and outputs.
A WPS can be configured to offer any sort of GIS functionality to clients across a network, including access to pre-programmed calculations and/or computation models that operate on spatially referenced data. The calculation can be extremely simple or highly complex, with any number of data inputs and outputs. A WPS may offer calculations as simple as subtracting one set of spatially referenced numbers from another (e.g., determining the difference in influenza cases between two different seasons), or as complicated as a global climate change model.
How does WPS work?
WPS uses three operations. The initial interaction with a WPS uses the GetCapabilities operation to return the list of process offered by that WPS. The inputs required by a process and the resulting outputs are described via the DescribeProcess operation, while the Execute operation allows a client to run a process.
WPS requests are based on HTTP Get and Post. The WPS standard specifies a request/response interface that defines how to:
- encode requests for process execution
- encode responses from process execution
- embed data and metadata in process execution inputs/outputs
- reference web-accessible data inputs/outputs
- support long-running processes
- return process status information
- return processing errors
- request storage of process outputs
- create a service chain.
Input data options
WPS is targeted at processes that involve geospatial data (vector and/or raster), but can also be applied to non-spatial processes.
The data required by the WPS can be delivered across a network, or available at the server.
WPS does not define or restrict the type of data required or output by a process. Instead, it identifies a generic mechanism to describe the data inputs required and produced. Thus data can include image data formats such as GeoTIFF, or data exchange standards such as GML. Data inputs can also be legitimate calls to OGC web services. For example, a data input for an intersection operation could be a polygon delivered in response to a WFS request, in which case the WPS data input would be the WFS query string.
WPS defines three types of data.
- Complex Data includes such things as imagery, XML, CSV, and custom or proprietary data structures.
- Literal Data includes single numerical values or text strings.
- Bounding Box Data includes geographic coordinates for a rectangular area.
Output response options
WPS allows several different approaches for executing a process:
Returning raw outputs
The simplest approach is only applicable when the WPS produces only one output. In this case, the output can be returned directly to the users in its raw form. For example, a request to buffer a feature could return an image of the buffered feature encoded in a png file.
Returning outputs embedded in XML.
One response to an Execute request is an XML document that includes metadata about the request, as well as the outputs from the process encoded and wrapped in the XML response. This form of response is recommended when the output size is less than a few megabytes in size, and the user requires metadata found in the wrapper.
A WPS may allow a user to request storage of the outputs. In this case, the XML document returned to the client will again contain metadata, but instead of the outputs themselves, it will contain references to web-accessible locations from which the outputs can be downloaded.
Finally, if an Execute request triggers a long-running process, the WPS will return a response containing references to the outputs as indicated aboved. Also included will be a reference to a location where the Execute response document is stored. The WPS will periodically update the status indicator found in this document until processing is complete.
Service Chaining with WPS
A WPS process is normally an atomic function that performs a specific geospatial calculation. Chaining of WPS processes facilitates the creation of repeatable workflows. WPS processes can be incorporated into service chains in a number of ways:
- Simple service chains can be encoded as part of the execute query. Such cascading service chains can be executed even via the GET interface.
- A WPS process can be designed to call a sequence of web services including other WPS processes, thus acting as the service chaining engine.
- A BPEL engine can be used to orchestrate a service chain that includes one or more WPS processes.