4.1. Process:

4.2. Process description:

4.3. Process input:

4.4. Process output:

4.5. Process profile:

4.6. WPS Server:

4.7. Process offering:

4.8. Process execution:

4.9. Job:

4.10. Service profiles for WPS:

6.1.  Abbreviated terms

6.2.  Use of the Term “Process”

The term process is one of the most used terms both in the information and geosciences domain. If not stated otherwise, this specification uses the term process as an umbrella term for any algorithm, calculation or model that either generates new data or transforms some input data into output data as defined in Clause 4.1.

6.3.  UML Notation

Unified Modeling Language (UML) static structure diagrams appearing in this specification are used as described in section 5.2 of OGC06-121r9. Further, the following conventions hold:

The UML model data dictionary is specified herein in a series of tables. The contents of the columns in these tables are described in section 5.5 of [OGC 06-121r9]. The contents of these data dictionary tables are normative, including any table footnotes.

6.4.  Namespace Conventions

The following namespaces are used in this document. The prefix abbreviations used constitute conventions used here, but are not normative. The namespaces to which the prefixes refer are normative, however.

7.1.  Service Discovery

Any WPS server shall be self-contained, i.e. provide an initial endpoint that can be used by a WPS client to determine the server’s capabilities.

7.2.  Service Capabilities

The basic capabilities of any WPS server fall into two categories: The first category comprises capabilities for process discovery and retrieval of process descriptions. The second category comprises capabilities to manage and monitor processing jobs.

Since the processes provided by a WPS server may have different degrees of complexity, the server shall indicate the allowed job control capabilities mode per process offering.

Further service capabilities, i.e. for secure communication and user authentication may be provided with the service but are neither covered nor restricted by this specification as long as they do not alter or change the semantics of other job control capabilities.

7.3.  Abstract Process Model

The abstract process model specifies generic requirements for process offerings that can be used in conjunction with WPS. Processes, as well as their inputs and outputs, are elements with identity. A process input may have arbitrarily defined value cardinality, i.e. for a given input, multiple datasets may be submitted for execution. A process output always has a value cardinality of one. Process inputs and outputs may also be nested. Identifiers for inputs and outputs shall be unique. For nested children it is sufficient to have a unique nesting path. Any input and output that does not have child elements shall have a defined data type so that a client is aware of the valid data formats for process execution.

The abstract process model provides many degrees of freedom for process descriptions. However, it does not enforce additional complexity for very simple processes.

Figure 2 — Abstract process model UML class diagram

Table 2 — Data encoding properties

7.4.  Job Control

The execution capability, that permits WPS clients to instantiate and run processing jobs, is the most prominent job control capability. Furthermore, the ability to dismiss or delete a job is useful for long-running processes in order to release server resources.

7.5.  Process Execution

Process executions on a WPS server may be run either synchronously (Figure 3) or asynchronously (see Figure 4). Synchronous execution is a suitable approach for jobs that take a relatively short time² to complete. Asynchronous execution is preferable for jobs that may take a long time to complete.

In the synchronous case, a WPS client submits an execute request to the WPS server and keeps listening for a response until the processing job has completed and the processing result has been returned. This requires a persistent connection between client and server.

Figure 3 — Synchronous process execution UML sequence diagram

In the asynchronous case, the client sends an execute request to the WPS server and immediately receives a status information response. This information confirms that the request was received and accepted by the server and that a processing job has been created and will be run in the future. The status information response also contains a processing job identifier that is used by the client when checking to see if execution has completed. (The client may also manage the processing job using available steering capabilities.) In addition, the status information response contains the result location, i.e. the URL where the processing result can be found after the processing job has completed.

Figure 4 — Asynchronous process execution UML sequence diagram

7.6.  Data Transmission by Value and by Reference

Data exchange between WPS clients and servers requires an agreement on the general data exchange patterns and suitable communication protocols. This specification defines two general data transmission modes for data exchange between WPS client and server.

Clients may send input data to or receive output data from a process in two distinct ways: (1) by reference, and (2) by value (see Figure 5). For brevity, this figure only shows the transmission patterns in the pure form, i.e. the same pattern is used for all inputs and outputs. However, mixed patterns are possible. Typically, small or atomic data such as integers, doubles or short strings are submitted by value. Large data inputs (outputs) are usually supplied by reference.

Figure 5 — Execute call and response "by value" and "by reference" UML sequence diagram.

This specification makes no assumptions about the encoding of the transmitted data. Due to the variety of data formats and supplementary encoding procedures, the receiver may not be able to automatically detect the data format. The set of encoding attributes that may be used by the receiver to decode inline or directly referenced data is defined by the data format description (see Table 2).

7.7.  Job Monitoring

By definition, a processing job is a server-side object created by a processing service in response for a particular process execution. It is comprised of a process definition (i.e. one of the process offerings defined in the WPS server’s capabilities), the input data provided or specified by the WPS client, and the outputs that are eventually delivered when the job has been completed.

Since the processing job is a server-side object, a WPS client has no means to inspect the status of a job on its own. Therefore, the server should provide a unique identifier for each job. For privacy, it is recommended to keep this identifier confidential between client and server.

For jobs running in asynchronous mode, the WPS server shall also provide monitoring information and it may also contain estimates on the completion time or additional elements related to status polling.

If a client finds a polling time in the status information, it shall respect it and behave accordingly. The service may rely on the client polling roughly around this time to obtain updated status information.

If a client finds an expiry date in the status information, it shall respect it and behave accordingly, i.e. ensure that the execution result is evaluated on time and the outputs are retrieved before the job is removed from the server. This requirement allows for robust WPS implementations and the timely re-allocation of server resources.

This section also defines a basic status set to communicate the status of a server-side job to the client. Extensions of this specification may introduce additional states for fine-grained monitoring or domain-specific purposes.

Table 3 — Basic status set for jobs

8.1.  Common Description Type

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

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

Table 4 — Properties of the DescriptionType structure

Table 5 — Properties of the Metadata structure

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.

Figure 7 — DataDescription and supported formats UML class diagram

Table 6 — Format properties

8.3.  Data Types

This specification defines three common data types for process input and output data (Figure 8):

Figure 8 — I/O data types overview

8.3.2.  Literal Data

The LiteralData type encodes atomic data such as scalars, linear units, or well-known names. Domains for LiteralData are a combination of data types (e.g. Double, Integer, String), a given value range, and an associated unit (e.g. meters, degrees Celsius).

Requirements class 16
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
Normative statements	Requirement 16-1 Requirements class for the literal data description. Requirement 16-2 Requirements class for the literal data values.

8.3.2.1.  LiteralData Description

The LiteralData description structure inherits essential elements from ows:DomainType allowing it to specify value domains including Units of Measure and Default Values. It restricts ows:DomainType by forbidding:

1. “NoValues” for a particular domain

2. the ability to specify further metadata on the values (since this information is already present at the level of input and output definitions in the DescriptionType element).

LiteralData data types should use the well-known types from XML Schema by their URI definition³. Table 11 lists the recommended URIs for the most common literal data types.

Requirements class 17
Obligation	requirement
Target type	Derived encoding and software implementation
Prerequisites	http://www.opengis.net/spec/WPS/2.0/req/conceptual-model http://www.opengis.net/spec/WPS/2.0/req/native-process/model/io-format OWS Common 2.0
Normative statement	Requirement 17-1 The description of valid literal data input and output shall comply with the structure defined in Figure 9, Table 8, Table 9, Table 10, and Table 11.

 

Figure 9 — LiteralData UML class diagram

Table 8 — The LiteralData structure

Names	Definition	Data type and values	Multiplicity and use
Format	Identifies a valid format for an input or output.	Format properties, see Table 6.	One or more (mandatory)
LiteralDataDomain	The valid domain for literal data	LiteralDataDomain type	One or more (mandatory)

Table 9 — Parts of the LiteralDataDomain structure

Names	Definition	Data type and values	Multiplicity and use
PossibleLiteralValues	Identifies a valid format for an input or output.	PossibleLiteralValuesChoice, see Table 10.	One (mandatory)
DataType	Reference to the data type of this set of values	ows:DataType. The use of well-known data type URNs is highly recommended; see Table 11.	One (mandatory)
UOM	Indicates that this quantity has units and provides the unit of measurement.	ows:ValuesUnit	Zero or one (optional) Include when values have units or reference system.
DefaultValue	Default value for this quantity.	ows:DefaultValue	Zero or one (optional) Include if there is a default.a
default	Indicates that this is the default/native domain.	Boolean, defaults to false.	Zero or one (conditional)b,c
a  For outputs, the DefaultValue has no meaning and shall thus be omitted. b  Defaults to FALSE if omitted. c  One of the formats included in the LiteralData structure shall have the attribute “default” set to “true”.

Table 10 — Parts of the PossibleLiteralValuesChoice structure

Names	Definition	Data type and values	Multiplicity and use
AllowedValues	List of all valid values and/or ranges of values for this quantity.	ows:AllowedValues	Zero or one (conditional)a
AnyValue	Specifies that any value is allowed for this quantity.	ows:AnyValue	Zero or one (conditional)a
ValuesReference	Reference to list of all valid values and/or ranges of values for this quantity.	ows:ValuesReference	Zero or one (conditional)a
a  One and only one of these three items shall be included.

Table 11 — Recommended data type URIs for literal data

Data Type	URI
String	http://www.w3.org/2001/XMLSchema#string
Integer	http://www.w3.org/2001/XMLSchema#integer
Decimal	http://www.w3.org/2001/XMLSchema#decimal
Boolean	http://www.w3.org/2001/XMLSchema#boolean
Double	http://www.w3.org/2001/XMLSchema#double
Float	http://www.w3.org/2001/XMLSchema#float

8.3.2.2.  LiteralData Values

LiteralData values represent values that correspond to a particular domain defined in the LiteralData structure. Figure 10 shows the mapping from the LiteralValue structure to the corresponding elements in the LiteralDataDescriptionType.

Requirements class 18
Obligation	requirement
Target type	Derived encoding and software implementation
Prerequisites	http://www.opengis.net/spec/WPS/2.0/req/conceptual-model http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/literal-data/description OWS Common 2.0
Normative statement	Requirement 18-1 The description of valid literal data values shall comply with the structure defined in Figure 10 and Table 12.

 

Figure 10 — LiteralValue UML class diagram

Table 12 — Parts of the LiteralValue structure

Names	Definition	Data type and values	Multiplicity and use
Value	String representation of the actual value.	Character String	One (mandatory)
dataType	The data type of the Value.	URI	Zero or one (optional)a
uom	The unit of measurement of the value.	URI	Zero or one (optional)a
a  If not specified, the relevant defaults from the LiteralData description (see Clause 8.3.2.1) will be used.

8.3.3.  BoundingBox Data

Bounding box data serves a variety of purposes in spatial data processing. Some simple applications are the definition of extents for a clipping operation or the definition of an analysis region. This specification inherits the bounding box specification from OWS Common.

Requirements class 19
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
Normative statement	Requirement 19-1 Requirements class for the bounding box data description. Requirements class for the bounding box data values.

8.3.3.1.  BoundingBox Description

The domain for bounding box data is described by a listing of supported CRSs.

Requirements class 20
Obligation	requirement
Target type	Derived encoding and software implementation
Prerequisites	http://www.opengis.net/spec/WPS/2.0/req/conceptual-model http://www.opengis.net/spec/WPS/2.0/req/native-process/model/io-format OWS Common 2.0
Normative statement	Requirement 20-1 The description of valid bounding box data input and output shall comply with the structure defined in Figure 11, Table 13, and Table 14.

 

Figure 11 — BoundingBoxData UML class diagram

Table 13 — The BoundingBox structure

Names	Definition	Data type and values	Multiplicity and use
Format	Identifies a valid format for an input or output.	Format properties, see Table 6.	One or more (mandatory)
SupportedCRS	The supported CRS for BoundingBox data.	SupportedCRS type, see Table 14.	One or more (mandatory)

Table 14 — The SupportedCRS type structure

Names	Definition	Data type and values	Multiplicity and use
CRS	Reference to a CRS definition.	URI	One or more (mandatory)
default	Indicates that this CRS is the default CRS.	Boolean, defaults to false.	Zero or one (conditional)a,b
a  Defaults to FALSE if omitted. b  One of the formats included in the BoundingBox structure shall have the attribute “default” set to “true”.

8.3.3.2.  BoundingBox Values

Values for bounding boxes are specified in the BoundingBox data type from OWS Common [OGC 06-121r9]. For consistency with the BoundingBoxData description, the specification of a CRS is mandatory.

Requirements class 21
Obligation	requirement
Target type	Derived encoding and software implementation
Prerequisites	http://www.opengis.net/spec/WPS/2.0/req/conceptual-model http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/bounding-box-data/description OWS Common 2.0
Normative statements	Requirement 21-1 The description of bounding box data values shall comply with the structure defined in OWS Common [OGC 06-121r9]. Requirement 21-2 The CRS component of the Bounding box values structure shall not be empty.

8.4.  Process Description

This section defines information structures that describe a process. It includes elements that link to documentation resources on the behavior and mechanics of a process as well as descriptive elements about its inputs and outputs. The process description model realizes and extends the requirements defined in the abstract process model in Clause 7.3.

A process description is an extension of the DescriptionType (Figure 12). It shall be used to express identifier, title, and abstract and to link to associated metadata elements that provide additional or more detailed information about the process. An additional language attribute shall be used to indicate the language of human readable elements in the description of the process and its inputs and outputs.

The description structures for process inputs and outputs inherit common elements from the DescriptionType (Clause 8.1). These elements shall be used to express identifier, title, and abstract and to link to associated metadata elements that provide additional or more detailed information about the process inputs and outputs. The content of human readable elements in the description of inputs and outputs shall adhere to the language indicated in the process description.

Process inputs are arguments to a process. Process inputs have a cardinality in order to (1) pass multiple values with the same identifier to a process, or (2) declare process inputs as optional (cardinality “0”). Input elements may be simple (i.e. the input has no sub-inputs attached) or aggregate (i.e. the input has one or more sub-input elements attached). A simple input includes a realization of the DataDescription element. An aggregate input contains one or more sub-inputs.

Outputs are the return values of a process. Outputs have a cardinality of one. Output elements may be simple (i.e. the output has no sub-outputs attached) or aggregate (i.e. the output has one or more sub-output elements attached). A simple output includes a realization of the DataDescription element. An aggregate output contains one or more sub-outputs.

Figure 12 — Process UML class diagram

Table 15 — The Process structure

Table 16 — Parts of the Input structure

Table 17 — Parts of the Output structure

8.5.  Process Profiles

Process profiles are blueprints for process implementations and are meant to harmonize process implementations to a certain degree. They serve as a reference for process implementations by providing a description of what the process actually does. While this specification does not attempt to enforce or suggest any particular process profiles, it provides a mechanism to define common processing functionality within the scope of WPS, thus supporting basic process cataloguing and retrieval tasks for distributed processing infrastructures. Depending on the degree of harmonization, the definitions of process profiles may be used to foster a common understanding of widely used processing functions. However, they may also be used to harmonize the technical details of process interfaces and thus document particular interoperability arrangements between process providers and consumers.

8.5.2.  Generic Process Profile

A generic profile is the abstract interface of a process. It provides a detailed description of the process mechanics and declares a signature for process inputs and outputs. The generic profile consists of a unique identifier and a generalized process description. This is similar to a process description as defined in Clause 8.4 but does not provide a definition of supported data exchange formats.

Example

A generic profile for a Buffer operation may be derived from the Buffer definition in the ISO standard for simple feature access [ISO 19125-1:2006]. The buffer method on simple features “Returns a geometric object that represents all points whose distance from this geometric object is less than or equal to distance. Calculations are in the spatial reference system of this geometric object” (ISO 19125-1:2006, subclause 6.1.2.4). This definition is specific about the conceptual data model details the behavior of the buffer method and the treatment of CRS units. In addition, it defines the name and data type of the distance parameter.

This generic definition of a Simple features buffer process may be inherited by multiple implementations that use arbitrary encodings for input and output data. The important part here is the well-defined behavior of the process at a generic level and the standardization of parameter names.⁴

Requirements class 25
Obligation	requirement
Target type	Derived encoding and software implementation
Prerequisites	http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process http://www.opengis.net/spec/WPS/2.0/req/native-process/model/description-type http://www.opengis.net/spec/WPS/2.0/req/native-process/model/description IETF RFC 4646
Normative statements	Requirement 25-1 A process description shall comply with the structure defined in Figure 13 and Table 18. Requirement 25-2 The language of the human-readable elements within the process description shall be identified by a language identifier as specified in IETF RFC 4646. Requirement 25-3 The description of process inputs and outputs shall comply with the structure defined in Figure 13, Table 19, and Table 20.

 

Figure 13 — GenericProcess UML class diagram

Table 18 — The GenericProcess structure

Names	Definition	Data type and values	Multiplicity and use
Title	Inherited from Table 4
Abstract
Keywords
Identifier
Metadata
Language	Language identifier for the human readable process description elements.	Character String. This language identifier shall be as specified in IETF RFC 4646.	One (mandatory)
Input	Input items (arguments) of a process.	GenericInput structure, see Table 19.	Zero or more (optional)
Output	Output items (results) of a process	GenericOutput structure, see Table 20.	One or more (mandatory)

Table 19 — Parts of the GenericInput structure

Names	Definition	Data type and values	Multiplicity and use
Title	Inherited from Table 4
Abstract
Keywords
Identifier
Metadata
minOccursa	Minimum number of times that values for this parameter are required	Non-negative integer; defaults to “1”, ‘0’ means the input is optional.	Zero or one (optional)
maxOccursa	Maximum number of times that this parameter may be present	Non-negative integer, defaults to “1”.	Zero or one (optional)
Input	Nested Input.b	GenericInput structure, Table 19 (this table).	Zero or more (optional)
a  The minOccurs and maxOccurs parameters have identical semantics to the like-named XML Schema occurrence constraints. b  It is recommended to keep the nesting level as low as possible.

Table 20 — Parts of the GenericOutput structure

Names	Definition	Data type and values	Multiplicity and use
Title	Inherited from Table 4
Abstract
Keywords
Identifier
Metadata
Output	Nested Output.a	GenericOutput structure, Table 20 (this table).	Zero or more (conditional)a
a  It is recommended to keep the nesting level as low as possible.

8.5.4.  Profile Inheritance

The hierarchical structure allows for inheritance between different types of profiles (see Figure 14). The definition and use of generic profiles for commonly used processing functions is generally recommended. However, there might be use cases for a product-specific harmonization of process interfaces. In this case, an implementation profile may be directly derived from a concept or defined in isolation.

If a profile in the hierarchy is derived from another profile at an equal or higher level, it must respect the inheritance rules given in Table 21. These rules ensure consistency in the use of identifiers, the specification of inputs and outputs as well as compliance to the behavior of the declared parent profiles.

Processes and process profiles may use metadata links to indicate compliance to a particular process profile. Links to particular profiles shall be embedded in the process’ metadata elements. The reserved role identifiers for the different profile levels are listed in Table 22.

An example which illustrates the inheritance rules for process profiles is given in Annex B.10.

Requirements class 27
Obligation	requirement
Target type	Derived encoding and software implementation
Prerequisites	http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/concept http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/generic http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/implementation http://www.opengis.net/spec/WPS/2.0/req/native-process/model/description
Normative statements	Requirement 27-1 Process profiles may inherit properties from profiles specified at a higher or equal level. The hierarchy is defined in Figure 14. Requirement 27-2 Inheriting process profiles and processes shall obey to the inheritance rules defined in Table 21. Requirement 27-3 Links to particular profiles are expressed in the DescriptionType’s metadata element as specified in Table 5. Requirement 27-4 The links target for profile metadata is the URL of the process profile. Requirement 27-5 The link roles defined in Table 22 shall be used to express the hierarchical level of the linked profile.

 

Figure 14 — Inheritance hierarchy for process profiles UML class diagram

Table 21 — Inheritance and override rules for process profiles

Property	Generic Profile	Implementation Profile	Implementation (instance level)
Process
Identifier	D	O	O
Title	D	O	O
Keywords	D	E	E
Abstract	D	O	O
Metadata	D	E/Oa	E/Oa
Input			Eb
Identifier	D	I	I
Title	D	I	I
Keywords	D	E	E
Abstract	D	I	I
Metadata	D	E/Oa	E/Oa
Multiplicity	D	Rc	Ed
Data format		D	Ed
Output			Eb
Identifier	D	I	I
Title	D	I	I
Keywords	D	E	E
Abstract	D	I	I
Metadata	D	O	O
Data format		D	Ed
NOTE:  D Declare (Introduction of a new property) I Inherit (A property is inherited from a superior level AND its value remains unchanged.) O Override (A property is inherited from a superior level AND its value is overridden.) E Extend (A property is inherited from a superior level AND its value is extended.) R Restrict (A property is inherited from a superior level AND its value is restricted.) a  The list of metadata references to superior process profiles shall be extended. Documentation metadata may be overridden, i.e. replaced by other documentation resources. b  Additional optional inputs or supplementary outputs may be added here. c  Implementation profiles may restrict the maximum cardinality of a superior generic profile (e.g. for theoretically infinite inputs). They shall not modify the minimum cardinality. d  Implementations may allow more or larger input datasets than the implementation profile, or support additional data exchange formats.

Table 22 — Role identifiers for process profiles

Profile level	URI
Process concept	http://www.opengis.net/spec/wps/2.0/def/process-profile/concept
Generic process profile	http://www.opengis.net/spec/wps/2.0/def/process-profile/generic
Process Implementation profile	http://www.opengis.net/spec/wps/2.0/def/process-profile/implementation

9.1.  XML Schema Implementation

This section specifies the XML encoding of the elements of the WPS native process model. The referred XML schema elements are provided by the associated schema package delivered with this standard and located at http://schemas.opengis.net/wps/2.0/.

9.2.  Plain Text Encoding for LiteralData and BoundingBoxData Values

This clause specifies the plain text encoding of data types for literal and bounding box data values.

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 schema5:
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

Listing

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 (see Clause 10.7).

DescribeProcess — This operation allows a client to request detailed metadata on selected processes offered by a server (see Clause 10.8).

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

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

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

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 15).

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 (Clause 10.12 and Clause 10.13) and conformance classes.

Figure 15 — 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.

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

Table 23 — Parts of the inline Data structure

Table 24 — Properties of the DataEncodingAttributes structure

Table 25 — Parts of the Reference structure

Table 26 — Parts of the RequestBody structure

Table 27 — Parts of the BodyReference structure

10.3.  WPS Service Handling

The WPS service model seeks compliance with OWS Common and implements the baseline communication protocol for OWS services and the related information elements defined in [OGC 06-121r9], clause 9.2.1.

Table 28 — Properties of the RequestBaseType

10.4.  Process Offering

A process offering structure contains information about the processes that may be run on a WPS server. Furthermore, the process offerings structure contains properties that describe the available execution modes of a process, the allowed data transmission modes, its version, and the process type (if it deviates from the native process model).

Table 29 — Parts of the ProcessOfferingPropertiesAttributes structure

Table 30 — Basic job control options

Table 31 — Data transmission options

10.5.  StatusInfo Document

The StatusInfo document is used to provide identification and status information about jobs on a WPS server.

Table 32 — StatusInfo structure

10.6.  Result Document

A Result document is a structure that contains the results of a process execution. It is a shared element between the Execute and GetResult operations.

Table 33 — Result structure

Table 34 — Parts of the DataOutputType structure

10.7.  GetCapabilities Operation

Per OGC 06-121r9, a GetCapabilities operation is required for any OGC Web service. For WPS, this operation allows a client to retrieve service metadata, basic process offerings, and the available processes present on a WPS server.

10.7.1.  GetCapabilities Request

The GetCapabilities request is mandatory for any OGC service. Figure 17 shows how the GetCapabilities request for a WPS relates to the generic GetCapabilitiesType defined by OWS Common. An Extension element provides a hook for further request parameters that may be defined by WPS extension specifications.

 

Figure 17 — GetCapabilities request UML class diagram

Requirements class 40
Obligation	requirement
Target type	Software implementation
Prerequisites	http://www.opengis.net/spec/WPS/2.0/req/conceptual-model OWS Common 2.0
Normative statements	Requirement 40-1 The GetCapabilities operation request shall be implemented as specified in Clause 7 of OWS Common [OGC 06-121r9]. Requirement 40-2 If the AcceptVersions parameter is contained in the request, it shall contain the character string “2.0.0”. Requirement 40-3 In addition to the properties inherited from OWS Common GetCapabilities, the WPS GetCapabilities request shall include the properties according to Table 35.

Table 35 — Additional properties in the GetCapabilities request

Names	Definition	Data type and values	Multiplicity and use
Service	Service type identifier	Character string, fixed to “WPS”	One (mandatory)
Extension	Container for elements defined by extension specifications	Any type. Value is defined by the extension specification.	Zero or more (optional)

10.7.2.  GetCapabilities Response

The response to a GetCapabilities operation is a document describing the service’s capabilities. Figure 18 shows how the WPS Capabilities are derived from the CapabilitiesBaseType defined in [OGC 06-121r9]. The OperationsMetadata element lists the request types supported by a WPS server. The contents section delivers information about the process offerings of the server. An Extension element provides a hook for additional service capabilities that cannot be covered by other available elements.

 

Figure 18 — Capabilities document UML class diagram

Requirements class 41
Obligation	requirement
Target type	Software implementation
Prerequisites	http://www.opengis.net/spec/WPS/2.0/req/conceptual-model OWS Common 2.0
Normative statements	Requirement 41-1 The capabilities response shall provide service metadata according to [OGC 06-121r9], clause 7.4.2. Requirement 41-2 The default version of the Capabilities document returned by a service implementing this standard shall be “2.0.0”. Requirement 41-3 In addition to the properties inherited from OWS Common OWSServiceMetadata, the WPS Capabilities shall include the properties according to Table 36. Requirement 41-4 The contents section of the Capabilities document shall contain a process summary for each of the process offerings. Requirement 41-5 The properties of a process summary shall provide the properties defined in Table 37.

Table 36 — Additional properties in the Capabilities document

Names	Definition	Data type and values	Multiplicity and use
service	Service type identifier	Character string, fixed to “WPS”	One (mandatory)
Contents	List of brief descriptions of the processes offered by this WPS server.	ProcessSummary, see Table 37	One (mandatory)
Extension	container for elements defined by extension specifications	Any type. Value is defined by the extension specification.	Zero or more (optional)

Table 37 — Properties of the ProcessSummary

Names	Definition	Data type and values	Multiplicity and use
Title	Title of a process, normally available for display to a human.	ows:Title	One (mandatory)
Abstract	Brief narrative description of a process, normally available for display to a human.	ows:Abstract	Zero or more (optional)
Keywords	Keywords that characterize a process,	ows:Keyword	Zero or more (optional)
Identifier	Unambiguous identifier or name of a process.	ows:Identifiera	One (mandatory)
Metadata	Reference to more metadata about this item.	ows:Metadata	Zero or more (optional) Include when available and useful
processModel	Inherited from Table 29.
jobControlOptions
outputTransmission
a  Additional content such as separate code space and version attributes in the Identifier element are not allowed.

10.8.  DescribeProcess Operation

The DescribeProcess operation allows WPS clients to query detailed process descriptions for the process offerings.

10.8.1.  DescribeProcess Request

The DescribeProcess request inherits basic properties from the RequestBaseType. An Identifier element shall contain a list of the process identifiers for which the process descriptions shall be obtained. If the service supports multilingual process descriptions, the desired language of the free-text elements in the process description may be queried with a language parameter.

Requirements class 44
Obligation	requirement
Target type	Software implementation
Prerequisites	http://www.opengis.net/spec/WPS/2.0/req/conceptual-model OWS Common 2.0 IETF RFC 4646 http://www.opengis.net/spec/WPS/2.0/req/service/model/handling
Normative statements	Requirement 44-1 The DescribeProcess request shall comply with the structure defined in Figure 19 and Table 38. Requirement 44-2 The reserved character string “ALL” shall be used to obtain a response that contains descriptions of all process offerings provided by the server.

 

Figure 19 — DescribeProcess request UML class diagram

Table 38 — Additional properties in the DescribeProcess request

Names	Definition	Data type and values	Multiplicity and use
Identifier	One or more process identifiers for which the detailed description shall be obtained.	ows:Identifier Value shall be one of the process identifiers listed in the ProcessSummary elements in the Capabilities document. The fixed value “ALL” indicates that the description of all process offerings shall be returned.	One or more (mandatory)
lang	Desired language of the process description.	xml:lang IETF RFC 4646 language code of the human-readable text elements in the process description (e.g. “en”). This shall be one of the languages defined in the Capabilities document.	Zero or one (optional)

10.9.  Execute Operation

The Execute operation allows WPS clients to run a specified process implemented by a server, using the input parameter values provided and returning the output values produced. Inputs may be included directly in the Execute request (by value), or reference web accessible resources (by reference). The outputs may be returned in the form of an XML response document, either embedded within the response document or stored as web accessible resources. Alternatively, for a single output, the server may be directed to return that output in its raw form without being wrapped in an XML response document. This is illustrated in Figure 20.

Figure 20 — Execute response document and raw data UML sequence diagram

10.9.1.  Execute Request

The Execute request is a common structure for synchronous and asynchronous execution. It inherits basic properties from the RequestBaseType and contains additional elements that identify the process that shall be executed, the data inputs and outputs, and the response type of the service.

Requirements class 48
Obligation	requirement
Target type	Software implementation
Prerequisites	http://www.opengis.net/spec/WPS/2.0/req/conceptual-model OWS Common 2.0 http://www.opengis.net/spec/WPS/2.0/req/service/model/handling
Normative statements	Requirement 48-1 The Execute request shall comply with the structure defined in Figure 21, Table 42, Table 43, and Table 44. Requirement 48-2 Raw data output shall only be requested if the processes execution will deliver one single output value. (For a process that provides more than one output, the desired output has to be specified in the request for raw data delivery.)

 

Figure 21 — Execute request UML class diagram

Table 42 — Additional properties in the Execute request

Names	Definition	Data type and values	Multiplicity and use
response	Desired response format, i.e. a response document or raw data.	String {rawa | document}	One (mandatory)
mode	Desired execution mode.	String{sync | async | autob} Valid values are to be derived from the jobControlOptions property of each ProcessOffering. “auto” delegates the choice of execution mode to the server.	One (mandatory)
Identifier	Unambiguous identifier of the process that shall be executed.	ows:Identifier Value shall be one of the process identifiers listed in the ProcessSummary elements in the Capabilities document.	One (mandatory)
Input	Data inputs provided to this process execution.	DataInputType structure, see Table 43.	Zero or more (conditional)c
Output	Specification of outputs expected from the process execution, including the desired format and transmission mode for each output.	OutputDefinitionType structure, see Table 44.	Zero or more (conditional)d
a  Raw output shall only be requested if the execution would return a single output. b  In the case of auto, the server shall respond quickly to avoid connection timeouts. c  If a process does not have any inputs, or if, for all required inputs the process description contains default values, this element may be omitted. d  If a process shall return all outputs in their default format, this element may be omitted.

Table 43 — Properties of the DataInputType

Names	Definition	Data type and values	Multiplicity and use
id	Identifier of a particular input, as defined in the process description.	URI	One (mandatory)
Data	The data provided for this input item.	Data structure, Table 23	Zero or one (conditional)a
Reference	HTTP resource that provides the input data.	Reference structure, Table 25	Zero or one (conditional)a
Input	Nested input, child element.	DataInputType structure, Table 43 (this table)	Zero or more (conditional)a
a  One and only one of these items shall be included.

Table 44 — Properties of the OutputDefinitionType

Names	Definition	Data type and values	Multiplicity and use
mimetype	See Table 24 — Properties of the DataEncodingAttributes structure.
encoding
schema
transmission	Code that indicates the desired data transmission mode for this output.	Character string. Valid values are listed in the outputTransmission property of each ProcessOffering.	Zero or one (conditional)a
id	Identifier of a particular output, as defined in the process description.	URI	One (mandatory)
Outputb	Nested output, child element.	OutputDefinitionType structure, Table 44 (this table).	Zero or morec (conditional)d
a  This element may be omitted for (1) raw data output, (2) output elements that serve as nesting parents. b  Depending on the process model, a client may provide a basic specification of the desired output format. This information shall ensure a successful decoding of the process outputs. Use and interpretation of this element shall be specified within a WPS service profile. c  See Figure 2 d  Include only for nested outputs.

10.10.  GetStatus Operation

The GetStatus operation allows WPS clients to query the status of an asynchronously executed job.

10.10.1.  GetStatus Request

The GetStatus request inherits basic properties from the RequestBaseType. It contains an additional element that identifies the JobID of the processing job, of which the status shall be returned.

Requirements class 52
Obligation	requirement
Target type	Software implementation
Prerequisites	http://www.opengis.net/spec/WPS/2.0/req/conceptual-model OWS Common 2.0 http://www.opengis.net/spec/WPS/2.0/req/service/model/handling
Normative statements	Requirement 52-1 GetStatus request shall comply with the structure defined in Figure 22 and Table 47. Requirement 52-2 The JobID used in the request shall be a valid identifier which the client has received with the execute response.

 

Figure 22 — GetStatus request UML class diagram

Table 47 — Additional properties in the GetStatus request

Names	Definition	Data type and values	Multiplicity and use
JobID	Job identifier.	Character String. This shall be a JobID the client has received during process execution.	One (mandatory)

10.11.  GetResult Operation

The GetResult operation allows WPS clients to query the result of a finished processing job. It is used in conjunction with asynchronous execution.

10.11.1.  GetResult Request

The GetResult request inherits basic properties from the RequestBaseType. It contains an additional element that identifies the JobID of the processing job, of which the result shall be returned.

Requirements class 56
Obligation	requirement
Target type	Software implementation
Prerequisites	http://www.opengis.net/spec/WPS/2.0/req/conceptual-model OWS Common 2.0 http://www.opengis.net/spec/WPS/2.0/req/service/model/handling
Normative statements	Requirement 56-1 The GetResult request shall comply with the structure defined in Figure 23 and Table 49. Requirement 56-2 The JobID used in the request shall be a valid identifier which the client has received with the execute response.

 

Figure 23 — GetResult request UML class diagram

Table 49 — Additional properties in the GetResult request

Names	Definition	Data type and values	Multiplicity and use
JobID	Job identifier.	Character String. This shall be a JobID the client has received during process execution.	One (mandatory)

10.12.  Synchronous WPS

The synchronous WPS is a requirements class profile that indicates the general availability of synchronous execution capabilities on a WPS server.

10.13.  Asynchronous WPS

The asynchronous WPS is a requirements class that indicates the general availability of asynchronous execution capabilities on a WPS server.

11.1.  HTTP/POST + XML Binding

This section specifies the encoding of WPS requests using HTTP/POST and XML. The referred XML schema elements are provided by the associated schema package delivered with this standard and located at http://schemas.opengis.net/wps/2.0/.

11.2.  HTTP/GET + KVP Binding

This section specifies the encoding of WPS requests using HTTP/GET and KVP. Since different HTTP client and server libraries may restrict the size of the URL this binding should only be used if the resulting HTTP/GET URL is reasonably short. The HTTP/GET + KVP binding is only defined for the operations GetCapabilities, DescribeProcess, GetStatus, and GetResult.⁸.

Any WPS request in the HTTP/GET + KVP binding consists of a URL with KVP parameters. The response is always an XML document defined for the HTTP/POST + XML binding.

12.1.  Basic WPS

The basic WPS is an aggregate requirements class that implements the WPS conceptual model based on the following requirements classes:

13.1.  Dismiss Operation

The dismiss operation is a job control operation. Its availability is indicated per process using the jobControlOptions in the ProcessSummary and the ProcessOffering structures.

13.1.1.  Dismiss Request

The Dismiss request inherits basic properties from the RequestBaseType. It contains an additional element that identifies the JobID of the processing job to be dismissed.

Requirements class 74
Obligation	requirement
Target type	Derived encoding and software implementation
Prerequisites	http://www.opengis.net/spec/WPS/2.0/req/conceptual-model OWS Common 2.0 http://www.opengis.net/spec/WPS/2.0/req/service/model/handling
Normative statements	Requirement 74-1 The Dismiss request shall comply with the structure defined in Figure 25 and Table 54. Requirement 74-2 The JobID used in the request shall be a valid identifier which the client has received with the execute response.

 

Figure 25 — Dismiss request UML class diagram

Table 54 — Additional properties in the Dismiss request

Names	Definition	Data type and values	Multiplicity and use
JobID	Job identifier.	Character String. This shall be a JobID the client has received during process execution.	One (mandatory)

13.2.  Binding Extensions for the Dismiss Operation