I.  Abstract

In many cases geospatial or location data, including data from sensors, must be processed before the information can be used effectively. The OGC Web Processing Service (WPS) Interface Standard provides a standard interface that simplifies the task of making simple or complex computational processing services accessible via web services. Such services include well-known processes found in GIS software as well as specialized processes for spatio-temporal modeling and simulation. While the OGC WPS standard was designed with spatial processing in mind, it can also be used to readily insert non-spatial processing tasks into a web services environment.

III.  Preface

This standard is a continuation of WPS 1.0, a standard for web-based processing of geospatial data. It incorporates a range of change requests that have been submitted since the release of WPS 1.0 and further follows the OGC standard for modular specifications [OGC 08-131r3].

In contrast to the prior version, WPS 2.0 provides a core conceptual model that may be used to specify a WPS in different architectures such as REST or SOAP.

The WPS process model has been encapsulated into separate requirements and conformance classes, so it may be used independently from WPS servers in process catalogs and metadata records. The expressive power of process descriptions has been enhanced by permitting structured (or nested) inputs and outputs. The concept of process profiles has been clarified and extended to support process descriptions at different levels of abstraction.

Conversely, the process model itself has been largely decoupled from the WPS protocol, allowing the use of other domain-specific descriptions of processes, e.g. those defined in SensorML, and to execute them on a WPS server.

This specification also provides a Basic WPS conformance class that comprises the synchronous and asynchronous execution protocol, the WPS process model, and implements HTTP/POST+XML and HTTP/GET+KVP encodings.

Future work will target the definition of process interfaces for common processes based on the process model conformance class. Such profiles will encourage the development of well-defined, reliable, interoperable and exchangeable process implementations.

If OGC baseline and related specifications should further progress towards REST-oriented interfaces, the development of a REST-oriented WPS interface standard should be considered.

1.  Scope

This document specifies the interface to a general purpose Web Processing Service (WPS). A WPS is a web service that enables the execution of computing processes and the retrieval of metadata describing their purpose and functionality. Typically, these processes combine raster, vector, and/or coverage data with well-defined algorithms to produce new raster, vector, and/or coverage information.

The WPS protocol supports both synchronous and asynchronous execution of processes. Synchronous execution may be used in simple and quick computation scenarios, where the data processing takes little to almost no time. Asynchronous processing is particularly well suited for complex computation scenarios which may take significant time.

The specification uses a core and extensions model to organize its features:

2.  Conformance

Conformance with this standard shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site¹.

Table 1 — Conformance classes related to WPS 2.0

3.  Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

Arliss Whiteside, Jim Greenwood: OGC 06-121r9, OGC Web Service Common Implementation Specification. Open Geospatial Consortium (2010). https://portal.ogc.org/files/?artifact_id=38867.

Policy SWG: OGC 08-131r3, The Specification Model — Standard for Modular specifications. Open Geospatial Consortium (2009). https://portal.ogc.org/files/?artifact_id=34762&version=2.

A. Phillips, M. Davis: IETF RFC 4646, Tags for Identifying Languages. RFC Publisher (2006). https://www.rfc-editor.org/info/rfc4646.

T. Berners-Lee, R. Fielding, L. Masinter: IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax. RFC Publisher (2005). https://www.rfc-editor.org/info/rfc3986.

ISO: ISO 8601:2004, Data elements and interchange formats — Information interchange — Representation of dates and times. International Organization for Standardization, Geneva (2004). https://www.iso.org/standard/40874.html.

W3C: W3C xmlschema-2, XML Schema Part 2: Datatypes Second Edition. World Wide Web Consortium https://www.w3.org/TR/xmlschema-2/.

4.  Terms and definitions

This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

For the purposes of this document, the following additional terms and definitions apply.

This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r9], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this standard.

For the purposes of this document, the following additional terms and definitions apply.

collection of data, published or curated by a single agent, and available for access or download in one or more formats

[SOURCE: W3C vocab-dcat]

represents an accessible form of a dataset

Example

[SOURCE: W3C vocab-dcat]

characteristic ALTERNATIVE

character DEPRECATED

abstraction of real world phenomena

[SOURCE: ISO 19101-1:2014, modified — added alternative term for “characteristic” and deprecated term “character”.]

A process p is a function that for each input returns a corresponding output

where $X$ denotes the domain of arguments x and $Y$ denotes the co-domain of values y. Within this specification, process arguments are referred to as process inputs and result values are referred to as process outputs. Processes that have no process inputs represent value generators that deliver constant or random process outputs.

A process description is an information model that specifies the interface of a process. A process description is used for a machine-readable description of the process itself but also provides some basic information about the process inputs and outputs.

6.  Conventions

This section provides details and examples for any conventions used in the document. Examples of conventions are symbols, abbreviations, use of XML schema, or special notes regarding how to read the document.

7.  WPS Conceptual Model

The WPS service model defines basic properties of any WPS server. A WPS server is a web service that provides access to pre-defined processes and provides job control operations to instantiate, control and monitor processing jobs (Figure 1).

Figure 1 — Artifacts of the WPS service model

8.  WPS Native Process Model

This section describes the information model of requirements. The corresponding XML and plain text encodings are specified in Clause 9.

8.1.  Common Description Type

Descriptive elements of processes, inputs and outputs are derived from the BasicIdentificationType provided by OWS Common (Figure 2). Other descriptive information shall be recorded in the Metadata element in the form of simple links with an appropriate role identifier.

Requirements class 5
Obligation	requirement
Target type	Derived encoding and software implementation
Prerequisites	http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process OWS Common 2.0 — BasicDescriptionType
Normative statements	Requirement 5-1 Process descriptions as well as the associated process inputs and outputs shall be derived from the OWS Common BasicIdentificationType. Requirement 5-2 The DescriptionType shall comply with the structure defined in Figure 2 and Table 2. Requirement 5-3 For linking documentation material or other metadata with the process itself, its inputs and its outputs, the metadata element from the BasicIdentificationType shall be used. Requirement 5-4 The metadata elements within process descriptions shall be simple links with a human-readable title (Table 3). Requirement 5-5 The metadata elements for documentation shall use the role identifier “http://www.opengis.net/spec/wps/2.0/def/process/description/documentation”.

 

Figure 2 — DescriptionType for processes, process inputs and process outputs UML class diagram

Table 2 — Properties of the DescriptionType structure

Names	Definition	Data type and values	Multiplicity and use
Title	Title of the process, input, and output. Normally available for display to a human.	ows:Title	One (mandatory)
Abstract	Brief narrative description of a process, input, and output. Normally available for display to a human.	ows:Abstract	Zero or one (optional) Include when available and useful.
Keywords	Keywords that characterize a process, its inputs, and outputs.	ows:Keywords	Zero or more (optional) Include when available and useful.
Identifier	Unambiguous identifier of a process, input, and output.	ows:Identifier Value is a URI or HTTP-URIa	One (mandatory)
Metadata	Reference to additional metadata about this item.	ows:Metadata Allowed values are specified in Table 3.	Zero or more (optional)
a  Additional content such as separate code space and version attributes in the Identifier element are not allowed.

Table 3 — Properties of the Metadata structure

Names	Definition	Data type and values	Multiplicity and use
Title	Title of the documentation. Normally available for display to a human.	Character String	One (mandatory)
Link type	Type of the xlink, fixed to simple.	Character String, fixed to “simple”.	One (mandatory)
Role	Role identifier, indicating the role of the linked document.	HTTP-URI	One (mandatory)
href	Reference to a documentation site for a process, input, or output.	HTTP-URI	One (mandatory)

8.2.  Data Description Structure

The DataDescription structure contains basic properties for defining data inputs and outputs, including mimetype, encoding and schema. These properties specify supported formats for input and output data of computing processes. Any input or output item may support multiple formats, one of which is the default format. Processes may require that an input or output data set does not exceed a certain data volume.

Requirements class 6
Obligation	requirement
Target type	Derived information model, encoding, and software implementation
Prerequisite	http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process
Normative statements	Requirement 6-1 Format descriptions of process inputs and outputs shall comply with the DataDescription structure defined in Figure 3 and Table 4. Requirement 6-2 One of the formats defined in the DataDescription structure shall be the default format, i.e. have the attribute “default” set to “true”.

 

Figure 3 — DataDescription and supported formats UML class diagram

Table 4 — Format properties

Names	Definition	Data type and values	Multiplicity and use
mimetype	Media type of the data.	Character String	One (mandatory)
encoding	Encoding procedure or character set of the data (e.g. raw or base64)	Character String, fixed to “simple”.	One (mandatory)
schema	Identification of the data schema.	HTTP-URI	One (mandatory)
maximumMegabytes	The maximum size of the input data, in megabytes.	Integer	Zero or one (optional)
default	Indicates that this format is the default format.a	Boolean	Zero or one (conditional)a, ,b
a  Defaults to FALSE if omitted. b  One of the formats included in the DataDescription structure shall have the attribute “default” set to “true”.

9.  WPS Native Process Model Encoding

Literal values - BNF schema:
literalvalue   = value *1("@datatype=" datatype) *1("@uom=" uom)
value          = 1*VCHAR
datatype  = URI
uom       = URI

Literal values - Example:
70@datatype=http://www.w3.org/2001/XMLSchema#integer@uom=meter

BoundingBox values - BNF schema2:
bbox      = lc_coords "," uc_coords ["," crs] ["," dimensions]
lc_coords = number ["," number]
uc_coords = number ["," number]
number         = 1*DIGIT["." 1*DIGIT]
crs       = 1*VCHAR
dimensions = 1*DIGIT

BoundingBoxData values - Examples:
51.9,7.0,53.0,8.0,EPSG:4326

51.9,7.0,53.0,8.0,http://www.opengis.net/def/crs/EPSG/0/4258

10.  Common WPS Service Model

A Web Processing Service consists of processes and service operations. By definition, processes represent the computational functionality of a WPS, while service operations are used to interact with the WPS and in particular to use the service’s process offerings.

10.1.  Overview of WPS Core Operations

The WPS interface specified in this section supports retrieval and execution of processes for geospatial computation. For that purpose, the WPS service model specifies the following operations that may be invoked by a WPS client and performed by a WPS server³:

GetCapabilities — This operation allows a client to request information about the server’s capabilities and processes offered.

DescribeProcess — This operation allows a client to request detailed metadata on selected processes offered by a server.

Execute — This operation allows a client to execute a process comprised of a process identifier, the desired data inputs and the desired output formats.

GetStatus — This operation allows a client to query status information of a processing job (conditional).

GetResult — This operation allows a client to query the results of a processing job (conditional).

During a sequence of WPS requests, a client should first issue a GetCapabilities request to the server to obtain an up-to date listing of available processes. Then, it may issue a DescribeProcess request to find out more details about particular processes offered, including the supported data formats. To run a process with the desired input data, a client will issue an Execute request⁴ (Figure 4).

The operations GetStatus and GetResult are used in conjunction with asynchronous execution. If a WPS server offers synchronous process execution only, these operations may not be implemented. Detailed guidance is provided by the corresponding profiles and conformance classes.

 

Figure 4 — Common sequence of WPS operations UML sequence diagram

10.2.  Data Transmission

Data exchange between WPS clients and servers requires an agreement on the general data exchange patterns and suitable communication protocols. Data may be sent to (received from) a WPS in two distinct ways: (1) by reference (using HTTP/GET or HTTP/POST), and (2) by value. Clients may send input data in either fashion. Output data may be requested in any fashion declared by the data transmission options defined for the process offering. Typically, large data inputs and outputs are delivered by reference.

Requirements class 13
Obligation	requirement
Target type	Derived encoding and software implementation
Prerequisite	http://www.opengis.net/spec/WPS/2.0/req/conceptual-model
Normative statement	Requirement 13-1 The data transmission structures for process inputs and outputs shall comply with the structures defined in Figure 5, Table 5, Table 6, Table 7, Table 8, and Table 9.

 

Figure 5 — Input and output data transmission structures UML class diagram

Table 5 — Parts of the inline Data structure

Names	Definition	Data type and values	Multiplicity and use
mimetype	See Table 6 — Properties of the DataEncodingAttributes structure.
encoding
schema
(any)a	The actual input or output data.	Any type and value	One (mandatory)
a  The data is embedded here as part of the Data element, in the mimeType, encoding, and schema indicated by the first three parameters if they exist, or by the relevant defaults.

Table 6 — Properties of the DataEncodingAttributes structure

Names	Definition	Data type and values	Multiplicity and use
mimetype	MimeType of the data.	Character String	One (mandatory)
encoding	Well-known encoding or character set of the data.	URI “raw” shall be used for plain binary data “base64” shall be used for base64 encoded data Character set identifiers (e.g. “UTF-8”) shall be used for text or CSV data.	Zero or one (conditional)a
schema	Identification of the data schema.	URI	Zero or one (conditional)a
a  This shall be provided if: 1) the process data item supports multiple encodings / schemas, and 2) the data is not of the default encoding / schema, and 3a) the schema / encoding cannot be retrieved from the data itself, or 3b) the encoding / schema information is deeply buried inside the data (i.e. not part of some header) and requires significant parsing effort.

Table 7 — Parts of the Reference structure

Names	Definition	Data type and values	Multiplicity and use
mimetype	See Table 6 — Properties of the DataEncodingAttributes structure.
encoding
schema
href	HTTP URI that points to the remote resource where the data may be retrieved.	HTTP URI	One (mandatory)
RequestBody	Request body element that is used for HTTP/POST requests to the above URL. If no request body is present, an HTTP/GET	Request should be used to retrieve the data. RequestBody structure, see Table 8.	Zero or one (optional)

Table 8 — Parts of the RequestBody structure

Names	Definition	Data type and values	Multiplicity and use
Body	The contents of this element to be used as the body of the HTTP request message to be sent to the service identified in ../Reference/@href. For example, it could be an XML encoded WFS request using HTTP/POST.	Any type	Zero or one (conditional)a
BodyReference	Reference to a remote document to be used as the body of an HTTP/POST request message to the service identified in the href element in the Reference structure (Table 7).	BodyReference, see Table 9.	Zero or one (conditional)a
a  One and only one of these items shall be included.

Table 9 — Parts of the BodyReference structure

Names	Definition	Data type and values	Multiplicity and use
href	HTTP URI that points to the remote resource where the request body may be retrieved.	HTTP URI	One (mandatory)

Bibliography

[1]  ISO: ISO 19101, Geographic information — Reference model. International Organization for Standardization, Geneva https://www.iso.org/standard/26002.html.

[2]  W3C: Data Catalog Vocabulary, W3C Recommendation 16 January 2014, https://www.w3.org/TR/vocab-dcat/