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.

The WPS standard provides a robust, interoperable, and versatile protocol for process execution on web services. It supports both immediate processing for computational tasks that take little time and asynchronous processing for more complex and time consuming tasks. Moreover, the WPS standard defines a general process model that is designed to provide an interoperable description of processing functions. It is intended to support process cataloguing and discovery in a distributed environment.

The following are keywords to be used by search engines and document catalogues.

geoprocessing, ogcdoc, OGC document, processes, processing, WPS

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.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

TU Dresden

52°North

Intergraph Corporation

Image Matters LLC

CRP Henri Tudor

Airbus Defence & Space

All questions regarding this submission should be directed to the editor or the submitters.

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:

1. A core conceptual model, defining basic requirements for a web based processing service,
2. A process model to support the description and discovery of processes on the web,
3. A basic data model that supports arbitrary (standard or non-standard) data formats for inputs and outputs,
4. A WPS service model and encoding based on OGC baseline standards, and
5. A Dismiss extension to allow clients to terminate asynchronous processing jobs.

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[1].

Normative References

The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

OGC 06-121r9, OGC Web Service Common Specification, version 2.0

OGC 08-131r3 – The Specification Model – A Standard for Modular Specifications

IETF RFC 4646: Tags for Identifying Languages

IETF RFC 3986: Uniform Resource Identifier (URI): Generic Syntax

ISO 8601:2004, Data elements and interchange formats – Information interchange – Representation of dates and times

XML Schema Part 2: Datatypes Second Edition, W3C Recommendation 28 October 2004.

Terms and Definitions

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.

4.1 Process

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.

4.2 Process description

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.

4.3 Process input

Process inputs are the arguments of a process and refer to data provided to a process. Each process input is an identifiable item.

4.4 Process output

Process outputs are the results of a process and refer to data returned by a process. Each process output is an identifiable item.

4.5 Process profile

A process profile is a description of a process on an interface level. Process profiles may have different levels of abstraction and cover several aspects. On a generic level, a process profile may only refer to the provided functionality of a process, i.e. by giving a verbal or formal definition how the outputs are derived from the inputs. On a concrete level a process profile may completely define inputs and outputs including data type definitions and formats.

4.6 WPS Server

A WPS Server is a web server that provides access to simple or complex computational processing services.

4.7 Process offering

A process offering is an identifiable process that may be executed on a particular service instance. A process offering contains a process description as well as service-specific information about the supported execution protocols (e.g. synchronous and asynchronous execution).

4.8 Process execution

The execution of a process is an action that calculates the outputs of a given process for a given set of data inputs.

4.9 Job

The (processing) job is a server-side object created by a processing service for a particular process execution. A job may be latent in the case of synchronous execution or explicit in the case of asynchronous execution. Since the client has only oblique access to a processing job, a Job ID is used to monitor and control a job.

4.10 Service profiles for WPS

A service profile for WPS is a conformance class that defines the general capabilities of a WPS server, by (1) specifying the supported service operations, (2) the process model, (3) the supported process execution modes, (4) the supported operation binding(s).

Conventions

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

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.

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.

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.

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.

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[2] 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.

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.

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.

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

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.

WPS Native Process Model

The WPS native process model is a realization of the abstract process model defined in section 6.3. The native process model breaks down into the following components:

1.   A general structure for process interface descriptions (sections 7.1, 7.4) that support process discovery and cataloging
2.   A set of data types to submit and receive data during process execution (sections 7.2, 7.3)
3.   A framework for defining process profiles to improve interoperability between different process implementations (section 7.5).

The native process model is encapsulated in a separate conformance class (A.4) and can be used independently from the rest of the WPS specification. It is designed to provide an interoperable description of processing functions, regardless whether they are offered by a web service for remote invocation, or reside in a Desktop GIS for local use. By abstracting from a concrete implementation this process model may be used to create metadata records in process catalogs or help comparing and aligning the processing functions in different systems.

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

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.

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.

Data Types

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

1. ComplexData, such as GML or geo-referenced imagery. This type is kept generic regarding the content and may be extended to provide more detailed domain-specific information.
2. LiteralData, defined as a value with an optional unit.
3. BoundingBoxData, defined as a minimum bounding rectangle in geographic coordinates.

Complex Data

The ComplexData type does not describe the particular structure for value encoding. Instead, the passed values must comply with the given format and the extended information, if provided.

ComplexData Description

The ComplexData structure is a direct realization of the abstract DataDescription element (Figure 7). It relies on the encoding attributes defined in Table 6 for a basic description of input and output data. In cases where these attributes do not sufficiently capture the structure and content of the required or produced data, the ComplexData element provides the ability to include any other descriptive elements next to the format specification. This hook may be used by process providers and consumers to communicate essential information and further constraints for input and output data items.

ComplexData Values

A Complex data value is directly passed to (or returned by) a process. The generic nature of Complex data does not permit a particular structure for value encoding. Instead, this structure is defined by the ComplexData description and the passed values must comply with the given format and the extended information, if provided.

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

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[5]. Table 11 lists the recommended URIs for the most common literal data types.

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.

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.

BoundingBox Description

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

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.

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 section 6.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 (section 7.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.

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.

Process Concept

A process concept is an object that provides high-level documentation about a general group of processes. It describes the purpose, methodology and properties of a process but not the specific input and output parameters. It is rather a documentation resource that may be referenced by refined process definitions to document their relation to a common principle.

Example: The concept “Buffer” may be used to describe all Buffer operations. More specific Buffer processes may be defined on raster or vector data models, be performed on a geoid or in CRS units, have further inputs, such as distance or tolerance and may even perform additional computations such as dissolve or line cap styling.

Due to the heterogeneity of process definitions and the variety of documentation requirements, there is no general information model for process concepts. Most of the time, concepts will be documented in HTML or similar multimedia formats. Formally, a concept consists of a unique identifier and a descriptive document.

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 7.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.[6]

Process Implementation Profile

Implementation profiles cover all descriptive elements of a process down to the supported data exchange formats. Technically they are process descriptions, but with the scope of a process profile, i.e., a harmonized and well-defined computing process that may be implemented by multiple service providers.

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.

WPS Native Process Model Encoding

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.0/.

Data Types

The XML encoding of data types defines encoding rules for ComplexData, LiteralData, BoundingBoxData as well as their values.

Examples for data type encodings are listed in Annex B.1.

Process Description

This clause specifies the XML encoding for the Process description.

A Process example is listed in Annex B.2.

Generic Process

This clause specifies the XML encoding for the GenericProcess.

A GenericProcess example is listed in Annex B.3.

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 schema[7]: 
 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 
   

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.

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[8]:

GetCapabilities – This operation allows a client to request information about the server’s capabilities and processes offered (see subclause 9.7).

DescribeProcess – This operation allows a client to request detailed metadata on selected processes offered by a server (see subclause 9.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 subclause 9.9).

GetStatus – This operation allows a client to query status information of a processing job (conditional, see subclause 9.10).

GetResult – This operation allows a client to query the results of a processing job (conditional, see subclause 9.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[9] (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 (sections 9.12 and 9.13) and conformance classes.

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.

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.

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

StatusInfo Document

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

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.

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.

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.

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.

GetCapabilities Exceptions

If a WPS server encounters an error while performing a GetCapabilities operation, it shall return an exception report as specified in Clause 7.4 of [OGC 06-121r9].

DescribeProcess Operation

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

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.

DescribeProcess Response

The response to a DescribeProcess operation is a ProcessOfferings document. This document contains a ProcessOfferings section for each available process on the server. In contrast to the ProcessSummary in the server’s capabilities, the processes are described in their declared description format.

DescribeProcess Exceptions

If a WPS server encounters an error while performing a DescribeProcess operation, it shall return an exception report as specified in Clause 8 of [OGC 06-121r9]. If the error was encountered due to an invalid process identifier, the server shall respond with the exception code defined in Table 41.

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.

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.

Execute Response

Depending on the desired execution mode and the response type declared in the execute request, the execute response may take one of three different forms: A response document, a StatusInfo document, or raw data.

Execute Exceptions

When a WPS server encounters an error while performing an Execute operation, it shall return an exception report as specified in clause 8 of [OGC 06-121r9]. If appropriate, the server shall use additional exception codes as defined in this section.

For synchronous execution, an exception is returned instead of a result. For asynchronous execution, it is recommended to return the exception at the earliest possible time. In the case of a syntactically wrong request (e.g. due to the use of wrong identifiers and data formats), the exception report message may be returned instead of a StatusInfo document. If the exception occurs later during execution, the StatusInfo shall be set to “Failed” and the GetResult operation shall be used to deliver the exception report.

GetStatus Operation

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

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.

GetStatus Response

The response to a GetStatus request is a StatusInfo document as defined in section 9.5.

GetStatus Exceptions

If a WPS server encounters an error while performing a GetStatus operation, it shall return an exception report as specified in Clause 8 of [OGC 06-121r9]. If the error was encountered due to an invalid process identifier, the server shall respond with the exception code defined in Table 48.

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.

GetResult Request

GetResult Response

The response to a GetResult request is a Processing Result document as defined in section 9.6.

GetResult Exceptions

When a WPS server encounters an error while performing a GetResult operation, it shall return an exception report as specified in Clause 8 of [OGC 06-121r9]. If the error was encountered due to an invalid JobID, the server shall respond with the exception code defined in Table 48 (NoSuchJob). If, for some reason, GetResult was invoked too early and the results have not been computed yet, the server shall respond with the exception defined in Table 50 (ResultNotReady).

If a job finishes with status “failed”, GetResult will provide the corresponding exception report. In this case, the appropriate exception codes defined for the execute operation shall be used.

Synchronous WPS

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

Asynchronous WPS

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

Binding Extensions for WPS Operations

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.0/.

GetCapabilities

This clause specifies the XML encoding for the GetCapabilities operation.

A GetCapabilities example is listed in Annex B.4.

DescribeProcess

This clause specifies the XML encoding for the DescribeProcess operation.

A DescribeProcess example is listed in Annex B.5.

Execute

This clause specifies the XML encoding for the Execute operation.

An Execute example is listed in Annex B.6.

GetStatus

This clause specifies the XML encoding for the GetStatus operation.

A GetStatus example is listed in Annex B.7.

GetResult

This clause specifies the XML encoding for the GetResult operation.

A GetResult example is listed in Annex B.8.

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.[10].

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.

GetCapabilities

This clause specifies the KVP encoding for the GetCapabilities operation. A minimalist GetCapabilities request might look like this:

http://hostname:port/path?service=WPS&request=GetCapabilities

DescribeProcess

This clause specifies the KVP encoding for the DescribeProcess operation. Possible DescribeProcess requests might look like these:

http://hostname:port/path?service=WPS&version=2.0.0&request=DescribeProcess&identifier=buffer,viewshed

http://hostname:port/path?service=WPS&version=2.0.0&request=DescribeProcess&identifier=ALL

GetStatus

This clause specifies the KVP encoding for the GetStatus operation. A possible GetStatus request might look like this:

http://hostname:port/path?service=WPS&version=2.0.0&request=GetStatus&jobid= FB6DD4B0-A2BB-11E3-A5E2-0800200C9A66

GetResult

This clause specifies the KVP encoding for the GetResult operation. A possible GetResult request might look like this:

http://hostname:port/path?service=WPS&version=2.0.0&request=GetResult&jobid= FB6DD4B0-A2BB-11E3-A5E2-0800200C9A66

Service Profiles

Basic WPS

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

1.   The WPS Service Model,
2.   The binding extensions defined in section 9.12, and
3.   The native WPS process model

Dismiss Extension

The dismiss extension for WPS allows a client to communicate to the server that he is no longer interested in the results of a job. In this case, the server may free all associated resources and “forget” the JobID (Figure 24). For jobs that are still running, the server may cancel the execution at any time. For jobs that were already finished, the associated status information and the stored results may be deleted without further notice, regardless of the expiration time given in the last status report.

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.

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.

Dismiss Response

The response to a Dismiss request is a StatusInfo document as defined in section 9.5. The status of the job shall be set to “Dismissed”. Subsequent requests to the service using the dismissed jobID shall result in a NoSuchJob exception.

Dismiss Exceptions

If a WPS server encounters an error while performing a Dismiss operation, it shall return an exception report as specified in Clause 8 of [OGC 06-121r9]. If the error was encountered due to an invalid JobID, the server shall respond with the exception code defined in Table 48 (NoSuchJob).

Binding Extensions for the Dismiss Operation

HTTP/POST + XML Binding

This clause specifies the XML encoding for the Dismiss operation.

A Dismiss example is listed in Annex B.9.

HTTP/GET + KVP Binding

This clause specifies the KVP encoding for the Dismiss operation. A possible Dismiss request might look like this:

http://hostname:port/path?service=WPS&version=2.0.0&request=dismiss&jobid= FB6DD4B0-A2BB-11E3-A5E2-0800200C9A66

Annex : Abstract Test Suite (Normative)

Tests and requirement identifiers below are relative to http://www.opengis.net/spec/WPS/2.0

Annex : XML Examples (informative)

B.1     Data Types

B.1.1 Complex Data Description

<wps:ComplexData>
  <wps:Format mimeType=“application/geotiff” encoding=“raw”
default=“true”/>
  <wps:Format mimeType=“application/geotiff” encoding=“base64”/>
</wps:ComplexData>

B.1.2 Literal Data Description

<wps:LiteralData>
  <wps:Format mimeType=“text/plain” default=“true”/>
  <wps:Format mimeType=“text/xml”/>
  <LiteralDataDomain default=“true”>
    <ows:AllowedValues>
      <ows:Range>
        <ows:MinimumValue>1</ows:MinimumValue>
        <ows:MaximumValue>1000</ows:MaximumValue>
      </ows:Range>
    </ows:AllowedValues>
    <ows:DataType
ows:reference=“http://www.w3.org/2001/XMLSchema#float”>float
</ows:DataType>
    <ows:UOM>meters</ows:UOM>
    <ows:DefaultValue>100</ows:DefaultValue>
  </LiteralDataDomain>
  <LiteralDataDomain>
    <ows:AllowedValues>
      <ows:Range>
        <ows:MinimumValue>1</ows:MinimumValue>
        <ows:MaximumValue>3000</ows:MaximumValue>
      </ows:Range>
    </ows:AllowedValues>
    <ows:DataType
ows:reference=“http://www.w3.org/2001/XMLSchema#float”>float
</ows:DataType>
    <ows:UOM>feet</ows:UOM>
  </LiteralDataDomain>
</wps:LiteralData>

B.1.3 Literal data values

<LiteralValue
  dataType=http://www.w3.org/2001/XMLSchema#double
  uom=“meter”>
    42.1
</LiteralValue>
 
<LiteralValue
  dataType=“http://www.w3.org/2001/XMLSchema#string”>
    ArableLand
</LiteralValue>

B.1.4 BoundingBox Data Description

<wps:BoundingBoxData>
  <wps:Format mimeType=“text/plain” default=“true”/>
  <wps:Format mimeType=“text/xml”/>
  <wps:SupportedCRS default=“true”>EPSG:4326</wps:SupportedCRS>
  <wps:SupportedCRS>
    http://www.opengis.net/def/crs/EPSG/0/4258
  </wps:SupportedCRS>
</wps:BoundingBoxData>

B.1.5 BoundingBox Data Values

<ows:BoundingBox crs=“EPSG:4326”>
  <ows:LowerCorner>51.9 7.0</ows:LowerCorner>
  <ows:UpperCorner>53.0 8.0</ows:UpperCorner>
</ows:BoundingBox>
 
<ows:BoundingBox
   crs=“http://www.opengis.net/def/crs/EPSG/0/4258”>
  <ows:LowerCorner>51.9 7.0</ows:LowerCorner>
  <ows:UpperCorner>53.0 8.0</ows:UpperCorner>
</ows:BoundingBox>

B.2     Process Description

This example describes a buffer command that accepts polygon coordinates in GML, and used a buffer distance in meters to produce a buffered polygon feature, which is output in GML.

<wps:Process xmlns:wps=“http://www.opengis.net/wps/2.0.0”
  xmlns:ows=“http://www.opengis.net/ows/2.0”
  xmlns:xlink=“http://www.w3.org/1999/xlink”
  xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
  xsi:schemaLocation=
“http://www.opengis.net/wps/2.0.0 ../../wps.xsd”>
 
  <ows:Title>Planar Buffer operation for GML features</ows:Title>
  <ows:Abstract>
  Create a buffer around a GML feature. Accepts any valid GML
  feature and computes the joint buffer.</ows:Abstract>
  <ows:Identifier>
    http://some.host/profileregistry/implementation/Planar-GML-
Buffer
  </ows:Identifier>
  <ows:Metadata
    xlink:role="http://www.opengis.net/spec/wps/2.0/def/
process-profile/concept"
    xlink:href="http://some.host/profileregistry/concept/
buffer"/>
  <ows:Metadata
    xlink:role="http://www.opengis.net/spec/wps/2.0/def/
process-profile/concept"
    xlink:href="http://some.host/profileregistry/concept/
planarbuffer"/>
  <ows:Metadata
    xlink:role="http://www.opengis.net/spec/wps/2.0/def/
process-profile/generic"
    xlink:href="http://some.host/profileregistry/generic/
SF-Buffer"/>
  <ows:Metadata
    xlink:role="http://www.opengis.net/spec/wps/2.0/def/
process/description/documentation"
    xlink:href="http://some.host/profileregistry/implementation/
Planar-GML-Buffer.html"/>
  <wps:Input>
    <ows:Title>Geometry to be buffered</ows:Title>
    <ows:Abstract>Geometry input in GML</ows:Abstract>
    <ows:Identifier>INPUT_GEOMETRY</ows:Identifier>
    <ows:Metadata
      xlink:role="http://www.opengis.net/spec/wps/2.0/def/
process/description/documentation"
      xlink:href="http://some.host/profileregistry/
implementation/Planar-GML-Buffer.html#input_geometry"/>
    <wps:ComplexData>
      <wps:Format mimeType=“text/xml” encoding=“UTF-8”
        schema=“http://schemas.opengis.net/gml/3.2.1/feature.xsd”
        default=“true”/>
    </wps:ComplexData>
  </wps:Input>
  <wps:Input minOccurs=“0”>
    <ows:Title>Distance</ows:Title>
    <ows:Abstract>
      Distance to be used to calculate buffer.
    </ows:Abstract>
    <ows:Identifier>DISTANCE</ows:Identifier>
    <ows:Metadata
      xlink:role="http://www.opengis.net/spec/wps/2.0/def/
process/description/documentation"
      xlink:href="http://some.host/profileregistry/
implementation/Planar-GML-Buffer.html#distance"/>
    <wps:LiteralData>
      <wps:Format mimeType=“text/plain” default=“true”/>
      <wps:Format mimeType=“text/xml”/>
      <LiteralDataDomain default=“true”>
        <ows:AllowedValues>
          <ows:Range>
            <ows:MinimumValue>1</ows:MinimumValue>
            <ows:MaximumValue>unbounded</ows:MaximumValue>
          </ows:Range>
        </ows:AllowedValues>
        <ows:DataType
          ows:reference="http://www.w3.org/2001/
XMLSchema#double">Double</ows:DataType>
      </LiteralDataDomain>
    </wps:LiteralData>
  </wps:Input>
  <wps:Output>
    <ows:Title>Buffered Geometry</ows:Title>
    <ows:Abstract>
      GML stream describing the buffered Geometry.</ows:Abstract>
    <ows:Identifier>BUFFERED_GEOMETRY</ows:Identifier>
    <ows:Metadata
      xlink:role="http://www.opengis.net/spec/wps/2.0/def/
process/description/documentation"
      xlink:href="http://some.host/profileregistry/
implementation/Planar-GML-Buffer.html#buffered_geometry"/>
    <wps:ComplexData>
      <wps:Format mimeType=“text/xml” encoding=“UTF-8”
        schema=“http://schemas.opengis.net/gml/3.2.1/feature.xsd”
        default=“true”/>
    </wps:ComplexData>
  </wps:Output>
</wps:Process>

B.3     Generic Process

This example describes a generic profile for a simple features buffer. It returns a geometry that represents all points whose distance from this Geometry is less than or equal to distance. Calculations are in the Spatial Reference System of this Geometry.

<wps:GenericProcess
  xmlns:ows=“http://www.opengis.net/ows/2.0”
  xmlns:wps=“http://www.opengis.net/wps/2.0.0”
  xmlns:xlink=“http://www.w3.org/1999/xlink”
  xmlns:xml=“http://www.w3.org/XML/1998/namespace”
  xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
  xsi:schemaLocation="http://www.opengis.net/wps/2.0.0
    ../../processProfile.xsd">
  <ows:Title>Simple Features Buffer</ows:Title>
  <ows:Identifier>http://some.host/profileregistry/generic/
    SF-Buffer</ows:Identifier>
  <ows:Metadata
    xlink:role="http://www.opengis.net/spec/wps/2.0/def/
process-profile/concept"
    xlink:href="http://some.host/profileregistry/
concept/buffer"/>
  <ows:Metadata
    xlink:role="http://www.opengis.net/spec/wps/2.0/def/
process-profile/concept"
    xlink:href="http://some.host/profileregistry/
concept/planarbuffer"/>
 
  <ows:Metadata
    xlink:role="http://www.opengis.net/spec/wps/2.0/def/
process/description/documentation"
    xlink:href="http://some.host/profileregistry/
generic/SF-Buffer.html"/>
  <wps:Input>
    <ows:Title>Input Geometry</ows:Title>
    <ows:Identifier>INPUT_GEOMETRY</ows:Identifier>
    <ows:Metadata
      xlink:role="http://www.opengis.net/spec/wps/2.0/def/
process/description/documentation"
      xlink:href="http://some.host/profileregistry/
generic/SF-Buffer.html#input_geometry"/>
  </wps:Input>
  <wps:Input>
    <ows:Title>Distance</ows:Title>
    <ows:Identifier>DISTANCE</ows:Identifier>
    <ows:Metadata
      xlink:role="http://www.opengis.net/spec/wps/2.0/def/
process/description/documentation"
      xlink:href="http://some.host/profileregistry/
generic/SF-Buffer.html#distance"/>
  </wps:Input>
  <wps:Output>
    <ows:Title>Buffered Geometry</ows:Title>
    <ows:Identifier>BUFFERED_GEOMETRY</ows:Identifier>
    <ows:Metadata
      xlink:role="http://www.opengis.net/spec/wps/2.0/def/
process/description/documentation"
      xlink:href="http://some.host/profileregistry/
generic/SF-Buffer.html#buffered_geometry"/>
  </wps:Output>
</wps:GenericProcess>

B.4     GetCapabilities

B.4.1 GetCapabilities Request

<wps:GetCapabilities service=“WPS”
  xmlns:ows=“http://www.opengis.net/ows/2.0”
  xmlns:wps=“http://www.opengis.net/wps/2.0.0”
  xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
  xsi:schemaLocation="http://www.opengis.net/wps/2.0.0
    ../wpsGetCapabilities.xsd">
</wps:GetCapabilities>

B.4.2 GetCapabilities Response

<wps:Capabilities service=“WPS” version=“2.0.0”
  xmlns:ows=“http://www.opengis.net/ows/2.0”
  xmlns:wps=“http://www.opengis.net/wps/2.0.0”
  xmlns:xlink=“http://www.w3.org/1999/xlink”
  xmlns:xml=“http://www.w3.org/XML/1998/namespace”
  xmlns:xs=“http://www.w3.org/2001/XMLSchema”
  xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
  xsi:schemaLocation="http://www.opengis.net/wps/2.0.0
../wpsGetCapabilities.xsd ">
  <ows:ServiceIdentification>
    <ows:Title>MyWebProcessingService</ows:Title>
    <ows:Abstract>
      A Web Processing Service offering typical GIS distance
      transform processes.
    </ows:Abstract>
    <ows:Keywords>
      <ows:Keyword>Geoprocessing</ows:Keyword>
      <ows:Keyword>Toolbox</ows:Keyword>
      <ows:Keyword>Distance transform</ows:Keyword>
    </ows:Keywords>
    <ows:ServiceType>WPS</ows:ServiceType>
    <ows:ServiceTypeVersion>2.0.0</ows:ServiceTypeVersion>
    <ows:Fees>NONE</ows:Fees>
    <ows:AccessConstraints>NONE</ows:AccessConstraints>
  </ows:ServiceIdentification>
  <ows:ServiceProvider>
    <ows:ProviderName>TU Dresden</ows:ProviderName>
    <ows:ProviderSite
xlink:href=“http://tu-dresden.de/geo/gis” />
    <ows:ServiceContact>
      <ows:IndividualName>Matthias Mueller</ows:IndividualName>
      <ows:ContactInfo>
        <ows:Address>
          <ows:ElectronicMailAddress>
            matthias_mueller@tu-dresden.de
          </ows:ElectronicMailAddress>
        </ows:Address>
      </ows:ContactInfo>
    </ows:ServiceContact>
  </ows:ServiceProvider>
  <ows:OperationsMetadata>
    <ows:Operation name=“GetCapabilities”>
      <ows:DCP>
        <ows:HTTP>
          <ows:Get
          xlink:href=“http://wps1.gis.geo.tu-dresden.de/wps”/>
        </ows:HTTP>
      </ows:DCP>
    </ows:Operation>
    <ows:Operation name=“DescribeProcess”>
      <ows:DCP>
        <ows:HTTP>
          <ows:Get
          xlink:href=“http://wps1.gis.geo.tu-dresden.de/wps”/>
          <ows:Post
          xlink:href=“http://wps1.gis.geo.tu-dresden.de/wps”/>
        </ows:HTTP>
      </ows:DCP>
    </ows:Operation>
    <ows:Operation name=“Execute”>
      <ows:DCP>
        <ows:HTTP>
          <ows:Post
          xlink:href=“http://wps1.gis.geo.tu-dresden.de/wps”/>
        </ows:HTTP>
      </ows:DCP>
    </ows:Operation>
    <ows:Operation name=“GetStatus”>
      <ows:DCP>
        <ows:HTTP>
          <ows:Get
          xlink:href=“http://wps1.gis.geo.tu-dresden.de/wps”/>
          <ows:Post
          xlink:href=“http://wps1.gis.geo.tu-dresden.de/wps”/>
        </ows:HTTP>
      </ows:DCP>
    </ows:Operation>
    <ows:Operation name=“GetResult”>
      <ows:DCP>
        <ows:HTTP>
          <ows:Get
          xlink:href=“http://wps1.gis.geo.tu-dresden.de/wps”/>
          <ows:Post
          xlink:href=“http://wps1.gis.geo.tu-dresden.de/wps”/>
        </ows:HTTP>
      </ows:DCP>
    </ows:Operation>
    <ows:Operation name=“Dismiss”>
      <ows:DCP>
        <ows:HTTP>
          <ows:Get
          xlink:href=“http://wps1.gis.geo.tu-dresden.de/wps”/>
          <ows:Post
          xlink:href=“http://wps1.gis.geo.tu-dresden.de/wps”/>
        </ows:HTTP>
      </ows:DCP>
    </ows:Operation>
  </ows:OperationsMetadata>
  <wps:Contents>
    <wps:ProcessSummary
jobControlOptions=“sync-execute async-execute dismiss”>
      <ows:Title>Euclidean Distance</ows:Title>
      <ows:Identifier>
        http://my.site/distance-transform/euclidean-distance
      </ows:Identifier>
    </wps:ProcessSummary>
    <wps:ProcessSummary
jobControlOptions=“async-execute dismiss”>
      processVersion=“1.4.0”>
      <ows:Title>Cost Distance</ows:Title>
      <ows:Identifier>
        http://my.site/distance-transform/cost-distance
      </ows:Identifier>
    </wps:ProcessSummary>
  </wps:Contents>
</wps:Capabilities>

B.5     DescribeProcess

B.5.1 DescribeProcess Request

<wps:DescribeProcess service=“WPS” version=“2.0.0”
  xmlns:ows=“http://www.opengis.net/ows/2.0”
  xmlns:wps=“http://www.opengis.net/wps/2.0.0”
  xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
  xsi:schemaLocation="http://www.opengis.net/wps/2.0.0
    ../wpsDescribeProcess.xsd">
  <ows:Identifier>Buffer</ows:Identifier>
  <ows:Identifier>Viewshed</ows:Identifier>
</wps:DescribeProcess>

B.5.2 DescribeProcess Response

<wps:ProcessOfferings xmlns:wps=“http://www.opengis.net/wps/2.0.0”
  xmlns:ows=http://www.opengis.net/ows/2.0
  xmlns:xlink=“http://www.w3.org/1999/xlink”
  xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
  xsi:schemaLocation="http://www.opengis.net/wps/2.0.0
../wpsDescribeProcess.xsd">
  <wps:ProcessOffering
jobControlOptions=“sync-execute async-execute dismiss”
outputTransmission=“value reference”>
    <wps:Process>      
      <ows:Title>
        Planar Buffer operation for Simple Features
      </ows:Title>
      <ows:Abstract>
        Create a buffer around Simple Feature geometries. Accepts
        any valid simple features input in GML or GeoJson and
        computes their joint buffer geometry.
      </ows:Abstract>
      <ows:Identifier>
        http://my.wps.server/processes/proximity/Planar-Buffer
      </ows:Identifier>
      <ows:Metadata
        xlink:role="http://www.opengis.net/spec/wps/2.0/
def/process-profile/concept"
        xlink:href="http://some.host/profileregistry/
concept/buffer"/>
      <ows:Metadata
        xlink:role="http://www.opengis.net/spec/wps/2.0/
def/process-profile/concept"
        xlink:href="http://some.host/profileregistry/
concept/planarbuffer"/>
      <ows:Metadata
        xlink:role="http://www.opengis.net/spec/wps/2.0/
def/process-profile/generic"
        xlink:href="http://some.host/profileregistry/
generic/SF-Buffer"/>
      <ows:Metadata
        xlink:role="http://www.opengis.net/spec/wps/2.0/
def/process/description/documentation"
        xlink:href="http://my.wps.server/processes/
proximity/Planar-Buffer.html"/>
      <wps:Input>
        <ows:Title>Geometry to be buffered</ows:Title>
        <ows:Abstract>
          Simple Features geometry input in GML or GeoJson
        </ows:Abstract>
        <ows:Identifier>INPUT_GEOMETRY</ows:Identifier>
        <ows:Metadata
          xlink:role="http://www.opengis.net/spec/wps/2.0/
def/process/description/documentation"
          xlink:href="http://my.wps.server/processes/
proximity/Planar-Buffer.html#input_geometry"/>
        <wps:ComplexData>
          <wps:Format mimeType=“text/xml” encoding=“UTF-8”
            schema="http://schemas.opengis.net/gml/
3.2.1/feature.xsd" default=“true”/>
          <wps:Format mimeType=“application/json”
encoding=“UTF-8”/>
        </wps:ComplexData>
      </wps:Input>
      <wps:Input minOccurs=“0”>
        <ows:Title>Distance</ows:Title>
        <ows:Abstract>
           Distance to be used to calculate buffer.
        </ows:Abstract>
        <ows:Identifier>DISTANCE</ows:Identifier>
        <ows:Metadata
          xlink:role="http://www.opengis.net/spec/wps/2.0/
def/process/description/documentation"
          xlink:href="http://my.wps.server/processes/
proximity/Planar-Buffer.html#distance"/>
        <wps:LiteralData>
          <wps:Format mimeType=“text/plain” default=“true”/>
          <wps:Format mimeType=“text/xml”/>
          <LiteralDataDomain default=“true”>
            <ows:AllowedValues>
              <ows:Range>
                <ows:MinimumValue>1</ows:MinimumValue>
                <ows:MaximumValue>unbounded</ows:MaximumValue>
              </ows:Range>
            </ows:AllowedValues>
            <ows:DataType
              ows:reference="http://www.w3.org/2001/
XMLSchema#double">
              Double
            </ows:DataType>
          </LiteralDataDomain>
        </wps:LiteralData>
      </wps:Input>
      <wps:Output>
        <ows:Title>Buffered Geometry</ows:Title>
        <ows:Abstract>
          Output Geometry in GML or GeoJson
        </ows:Abstract>
        <ows:Identifier>BUFFERED_GEOMETRY</ows:Identifier>
        <ows:Metadata
          xlink:role="http://www.opengis.net/spec/wps/2.0/
def/process/description/documentation"
          xlink:href="http://my.wps.server/processes/
proximity/Planar-Buffer.html#buffered_geometry"/>
        <wps:ComplexData>
          <wps:Format mimeType=“text/xml” encoding=“UTF-8”
            schema="http://schemas.opengis.net/gml/
3.2.1/feature.xsd" default=“true”/>
          <wps:Format mimeType=“application/json”
encoding=“UTF-8”/>
        </wps:ComplexData>
      </wps:Output>
    </wps:Process>
  </wps:ProcessOffering>
</wps:ProcessOfferings>

B.6     Execute

B.6.1 Execute Request (asynchronous, result document)

<wps:Execute
  xmlns:wps=“http://www.opengis.net/wps/2.0.0”
  xmlns:ows=“http://www.opengis.net/ows/2.0”
  xmlns:xlink=“http://www.w3.org/1999/xlink”
  xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
  xsi:schemaLocation="http://www.opengis.net/wps/2.0.0
../wpsExecute.xsd"
  service=“WPS” version=“2.0.0” response=“document”
mode=“async”>
  <ows:Identifier>
    http://my.wps.server/processes/proximity/Planar-Buffer
  </ows:Identifier>
  <wps:Input id=”INPUT_GEOMETRY”>
    <wps:Reference xlink:href="http://some.data.server/
mygmldata.xml"/>
  </wps:Input>
  <wps:Input id=”DISTANCE”>
    <wps:Data>10</wps:Data>
  </wps:Input>
  <!– Uses default output format –>
  <wps:Output id=”BUFFERED_GEOMETRY”
wps:dataTransmissionMode=“reference”>
  </wps:Output>
</wps:Execute>

B.6.2 Execute Response (StatusInfo)

<wps:StatusInfo xmlns:ows=“http://www.opengis.net/ows/2.0”
  xmlns:wps=“http://www.opengis.net/wps/2.0.0”
  xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
  xsi:schemaLocation="http://www.opengis.net/wps/2.0.0
../wpsStatusInfo.xsd">
  <wps:JobID>FB6DD4B0-A2BB-11E3-A5E2-0800200C9A66</wps:JobID>
  <wps:Status>Accepted</wps:Status>
  <wps:NextPoll>2014-12-24T16:00:00Z</wps:NextPoll>
</wps:StatusInfo>

B.6.3 Execute Response (Result)

<wps:Result
  xmlns:ows=“http://www.opengis.net/ows/2.0”
  xmlns:wps=“http://www.opengis.net/wps/2.0.0”
  xmlns:xlink=“http://www.w3.org/1999/xlink”
  xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
  xsi:schemaLocation="http://www.opengis.net/wps/2.0.0
../wpsGetResult.xsd ">
  <wps:JobID>FB6DD4B0-A2BB-11E3-A5E2-0800200C9A66</wps:JobID>
  <wps:ExpirationDate>2014-12-24T24:00:00Z</wps:ExpirationDate>
  <wps:Output id=”BUFFERED_GEOMETRY”>
    <wps:Reference
      xlink:href="http://result.data.server/
FB6DD4B0-A2BB-11E3-A5E2-0800200C9A66/
BUFFERED_GEOMETRY.xml"/>
  </wps:Output>
</wps:Result>

B.7     GetStatus

B.7.1 GetStatus Request

<wps:GetStatus service=“WPS” version=“2.0.0”
  xmlns:wps=“http://www.opengis.net/wps/2.0.0”
  xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
  xsi:schemaLocation="http://www.opengis.net/wps/2.0.0
    ../wpsStatusInfo.xsd ">
  <wps:JobID>FB6DD4B0-A2BB-11E3-A5E2-0800200C9A66</wps:JobID>
</wps:GetStatus>

B.7.2 GetStatus Response

<wps:StatusInfo xmlns:ows=“http://www.opengis.net/ows/2.0”
  xmlns:wps=“http://www.opengis.net/wps/2.0.0”
  xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
  xsi:schemaLocation="http://www.opengis.net/wps/2.0.0
../wpsStatusInfo.xsd">
  <wps:JobID>FB6DD4B0-A2BB-11E3-A5E2-0800200C9A66</wps:JobID>
  <wps:Status>Running</wps:Status>
  <wps:NextPoll>2014-12-24T16:00:00Z</wps:NextPoll>
</wps:StatusInfo>

B.8     GetResult

B.8.1 GetResult Request

<wps:GetResult service=“WPS” version=“2.0.0”
  xmlns:wps=“http://www.opengis.net/wps/2.0.0”
  xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
  xsi:schemaLocation="http://www.opengis.net/wps/2.0.0
../wpsGetResult.xsd ">
  <wps:JobID>FB6DD4B0-A2BB-11E3-A5E2-0800200C9A66</wps:JobID>
</wps:GetResult>

B.8.2 GetResult Response

See Annex B.6.3.

B.9     Dismiss

B.9.1 Dismiss Request

<wps:Dismiss service=“WPS” version=“2.0.0”
  xmlns:wps=“http://www.opengis.net/wps/2.0.0”
  xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
  xsi:schemaLocation="http://www.opengis.net/wps/2.0.0
../wpsDismiss.xsd ">
  <wps:JobID>FB6DD4B0-A2BB-11E3-A5E2-0800200C9A66</wps:JobID>
</wps:Dismiss>

B.9.2 Dismiss Response

<wps:StatusInfo xmlns:ows=“http://www.opengis.net/ows/2.0”
  xmlns:wps=“http://www.opengis.net/wps/2.0.0”
  xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
  xsi:schemaLocation="http://www.opengis.net/wps/2.0.0
../wpsStatusInfo.xsd">
  <wps:JobID>FB6DD4B0-A2BB-11E3-A5E2-0800200C9A66</wps:JobID>
  <wps:Status>Dismissed</wps:Status>
</wps:StatusInfo>

B.10  Profile inheritance example

Taking the example of a simple Mosaic process, Figure 26 and Figure 27 illustrate the inheritance rules for process profiles provided in section 7.5.4. In its most simple form, a mosaic process transforms a set if tiles (Coverages or georeferenced imagery) into a single output dataset. Starting from the conceptual level, the process definition is incrementally refined until the specificity of an implementation profile is reached. At the level of a profile implementation, e.g. on a particular WPS instance, the implementer may still extend the contract of the implementation profile (e.g. by allowing more or larger input data).