Web Processing Service (WPS)

Overview

A Web Processing Service (WPS) provides access to calculations or models which operate on spatially referenced data. A WPS can be configured to offer any sort of Geographic Information System (GIS) functionality to clients across a network, including access to pre-programmed calculations and/or computation models. The WPS standard provides a mechanism to identify the spatially-referenced data required by the calculation, to initiate the calculation, and to manage the output from the calculation so that it can be accessed by the client.

A WPS may offer calculations as simple as subtracting one set of spatially referenced numbers from another (e.g., to determine the difference in the number of influenza cases between two different seasons), or as complicated as a global climate change model. The data required by the WPS can be delivered across a network or available at the server, and can use data identification and exchange standards that include Geography Markup Language (GML), a Table Joining Service (TJS) or Catalogue Services for the Web (CSW).

Additional Information

Standard

OGC® Web Processing Service

Related Information

Geography Markup Language (GML)

Table Joining Service (TJS)

Catalogue Services for the Web (CSW)

Web Feature Service (WFS)

Web Map Service (WMS)

Notes

The Web Processing Service standard has been developed and published by the Open Geospatial Consortium (OGC).

Additional Information: Web Processing Service (WPS)

Background

WPS Standard

WPS Operations

WPS Mechanisms

WPS Application Profiles

Background

The Web Processing Service (WPS) standard is the result of work initially undertaken to support the Canadian Geospatial Data Infrastructure (CGDI) and, in particular, the National Land and Water Information Service (NLWIS) and the National Forest Information Service (NFIS). The standard was first implemented as a prototype in 2004 by Agriculture and Agri-Food Canada (AAFC). In the first half of 2005, it was the subject of a successful OGC® Interoperability Experiment.

The WPS was originally named the Geoprocessing Service. The name was changed to "Web Processing Service" early in its development to avoid the acronym GPS, because this would have caused confusion with the conventional use of this acronym for the Global Positioning System. Since WPS has evolved as an OGC® standard, the term “geospatial” would have also been redundant. The original version of the WPS standard was released in September 2005; the current OGC® Web Processing Service replaces all earlier drafts.

WPS Standard

The OGC® Web Processing Service standard prescribes the interface to a WPS, and provides rules for standardizing inputs and outputs (requests and responses) for geospatial processing services, such as polygon overlay. The standard also defines how a client can request the execution of a process, and how the output from the process is handled. It defines an interface that facilitates the publishing of geospatial processes and clients’ discovery of and binding to those processes. For WPS, publishing means making available machine-readable binding information as well as human-readable metadata that allows service discovery and use. Geospatial processes may include any algorithm, calculation or model that operates on spatially referenced data.

AWPS can be configured to offer any sort of GIS functionality to clients, including access to pre-programmed calculations and/or computation models. A WPS can process vector features or raster data, or perform other data processing. The service is applicable to any algorithm where all the inputs are provided to the process at start-up. It does not support client interactions during run-time. The data required by the WPS can be delivered across a network, or available locally on the client server.

The WPS standard is designed to allow a service provider to expose a web accessible process, such as polygon intersection, in a way that permits clients to input data and execute the process with no specialized knowledge of the underlying physical process interface or Application Profile. Because WPS offers a generic interface, it can be used to wrap other existing and planned services that focus on providing geospatial processing services. It provides a way to expose a mathematical calculation for geospatial information to the Internet and allows users to:

1. Advertise the calculations that it can run;
2. Name required data inputs, including formats;
3. Run data identified by a client through the model;
4. Report on the status of the calculation, including completion;
5. Arrange for storage of the output, if requested; and
6. Return output, or provide a URL that points to the output.

A WPS provides clients with access across a network to pre-programmed calculations and/or computation models. The calculation can be extremely simple or highly complex, with any number of data inputs and outputs. The WPS standard does not define the specific processes that could be implemented by a WPS; instead, it provides a generic mechanism that can be used to describe and web-enable any sort of geospatial process. Enabling geospatial processing on the Internet requires the development of a wide variety of web services to support geospatial operations, as well as sophisticated modelling capabilities. It is important to standardize the way that these processes are referenced, in order to reduce the amount of programming required, and to facilitate the implementation and adoption of new services.

To achieve interoperability, each process, and the related data inputs, must be specified in a separate document, which might be called an Application Profile. This data can include image data formats such as GeoTIFF, or data exchange standards such as Geography Markup Language (GML).

For example: a data input for an intersection operation could be a polygon delivered in response to a Web Feature Service (WFS) request, in which case the WPS data input would be the WFS query string.

Note that the WPS standard does not address the cataloguing, discovery, retrieval or archiving of information that has been created by a WPS.

WPS Operations

The WPS standard includes three mandatory operations that can be requested by a client and performed by a WPS server. These operations can be accessed using HTTP GET and HTTP POST. They are:

• GetCapabilities– allows a client to request and receive service metadata (or capabilities) documents that describe the abilities of the specific server implementation and to list the processes it can execute.
• The response to a GetCapabilities operation is an XML file that contains the operations that the implementation supports, and a list of the names and general descriptions of each of the processes (i.e. models, calculations, or algorithms) offered by a WPS instance, as well as the languages it supports. This operation also permits negotiation of the specification version being used for client-server interactions.
• DescribeProcess– allows a client to request and receive detailed information about the processes that can be run on the service instance, including the inputs required, their allowable formats, and the outputs that can be produced. It provides a means for a client to determine what the mandatory, optional, and default parameters are for a particular process, as well as the format of the data inputs and outputs.
• Execute– allows a client to run a specified process implemented by the WPS, using input parameter values specified by the client. These input values must be identified, as defined in the Process Description, and these values may be references to datasets accessible via the Internet.

The resulting outputs can be returned either as a direct response to the request, or the process can be directed to store the results as a web accessible resource, in which case the direct response identifies the location of that resource.

Example: Consider the simple case of a process that can intersect two polygons.

The response to a GetCapabilities request might indicate that the WPS supports an operation called “Intersect”, and that this operation is limited to intersecting one polygon with a second polygon.

The response to a DescribeProcess request for the “Intersect” process might indicate that it requires two inputs, namely: FirstPolygon and SecondPolygon, and that these inputs must be provided in GML. Furthermore, the process will produce one output in GML, and it can be delivered as a web-accessible resource.

The client would then run the process by using the Execute operation, might choose to provide the two input polygons embedded directly within the request, and identify that the output should be stored as a web-accessible resource.

After completion, the process would return an ExecuteResponse XML document that identifies the inputs and outputs, indicates whether or not the process executed successfully and, if successful, contains a reference to the web-accessible outputs.

These operations have many similarities to other standard web services, including the Web Map Service (WMS), the Web Feature Service (WFS), and the Web Coverage Service (WCS). The interface aspects that these other services have in common with WPS are prescribed in the OGC® Web Services Common Implementation Specification.

WPS Mechanisms

WPS is a generic interface because it does not identify any specific processes that are supported. Instead, each implementation of WPS defines the processes that it supports, as well as their associated inputs and outputs. WPS can be thought of as an abstract model of a web service, for which profiles need to be developed to support use, and standardized to permit interoperability. As with other specifications (including Geography Markup Language (GML) and Catalogue Services for the Web (CSW)), it is the development, publication, and adoption of profiles that define the specific uses of the WPS standard.

WPS discovery and binding mechanisms follow the model set by Web Map Service (WMS) and Web Feature Service (WFS), in that WPS defines a GetCapabilities operation, and requests are based on HTTP GET and HTTP POST. WPS does more than just describe the service interface; it 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; and
• Request storage of process outputs.

WPS permits the provision of input data using two different methods. Data can be:

• Embedded in the Execute request, where the WPS acts as a stand-alone service; or
• Referenced as a web accessible resource, where the WPS acts as a middleware service for data, by obtaining data from an external resource in order to run a software process for local implementation.

WPS Application Profiles

The WPS standard allows service developers to reuse significant amounts of code in the development of web interfaces, while facilitating ease of understanding among web application developers. However, fully automated interoperability can be achieved only through the use of standardized profiles. While it is possible to write a generic client for WPS, the use of a profile enables optimization of interoperable client/user interface behaviour, as well as the publish/find/bind paradigm.

To achieve high interoperability, each process must be specified in a WPS Application Profile that describes how WPS must be configured to serve a process that can be easily recognized. An Application Profile consists of

1. An OGC® URN^{Footnote 1} that uniquely identifies the process. (mandatory)
2. A reference response to a DescribeProcess request for that process. (mandatory)
3. A human-readable document that describes the process and its implementation. (optional, but recommended)
4. A WSDL^{Footnote 2} description for that process. (optional)

WPS Application Profiles are intended for consumption by web service registries that maintain searchable metadata for multiple service instances. Geospatial infrastructures can establish a geospatial processing web by specifying a repository that contains a semantically defined hierarchy of processes, each identified by a URN. A WPS Application Profile defines each unique process within the repository, and each WPS instance can refer to that URN. The WPS standard fully supports this approach to standardized semantically-driven service discovery.