License Agreement

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.

THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.


 

i. Abstract

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

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.

ii. Keywords

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

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

iii. Preface

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

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

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

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

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

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

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

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.

iv. Submitting organizations

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

 

v. Submitters

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


Name Representing OGC Member

Matthias Müller

TU Dresden

Yes

Benjamin Pross

52°North

Yes

Stan Tillman

Intergraph Corporation

Yes

Jeff Yutzler

Image Matters LLC

Yes

Luís de Sousa

CRP Henri Tudor

Yes

Arnaud Cauchy

Airbus Defence & Space

Yes


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

 

Table 1 – Conformance classes related to WPS 2.0
Conformance Class Description Clause
http://www.opengis.net/spec/WPS/2.0/conf/service/profile/basic-wps Basic WPS service profile A.1
http://www.opengis.net/spec/WPS/2.0/conf/service/synchronous-wps Synchronous WPS A.2
http://www.opengis.net/spec/WPS/2.0/conf/service/asynchronous-wps Asynchronous WPS A.3
http://www.opengis.net/spec/WPS/2.0/conf/process-model-encoding WPS process model encoding A.4
http://www.opengis.net/spec/WPS/2.0/conf/service/dismiss-extension Dismiss extension A.6

 

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

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

Abbreviated terms

CRS
  Coordinate Reference System
GML
  Geography Markup Language
HTTP
  Hypertext Transfer Protocol
ISO
  International Organization for Standardization
KVP
  Keyword Value Pair
MIME
  Multipurpose Internet Mail Extensions
OGC
  Open Geospatial Consortium
UML
  Unified Modeling Language
URI
  Universal Resource Identifier
URL
  Uniform Resource Locator
WPS
  Web Processing Service
XML
  Extensible Markup Language

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 section 4.1.

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:

  •   UML elements having a package name of “OWS Common” are those defined in the UML model of OWS Common [OGC 06-121r9].
  •   UML data type Any is used here as an equivalence to XML’s xsd:any.
  •   UML elements not qualified with a package name are those defined in this standard.

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.

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.

Prefix Namespace URI Description
ows http://www.opengis.net/ows/2.0 OWS Common 2.0 XML Schema
xlink http://www.w3.org/1999/xlink Definitions for XLINK
xml http://www.w3.org/XML/1998/namespace XML (required for xml:lang)
xs http://www.w3.org/2001/XMLSchema XML Schema

 

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

Artifacts of the WPS service model
Figure : Artifacts of the WPS service model

 

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/conceptual-model
Target type Derived information model, encoding, and software implementation
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/discovery Requirements class for service discovery.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/capabilities Requirements class for service capabilities.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process-model Requirements class for supported process models.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/job-control Requirements class for job control.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process-execution Requirements class for process execution.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/data-transmission Requirements class for data transmission between service and client.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/job-monitoring Requirements class for job monitoring.

 

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.

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/discovery
Target type Derived information model, encoding, and software implementation
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/discovery/endpoint All WPS servers shall have an initial end-point (HTTP URI).
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/discovery/capabilities The service shall provide a systematic discovery mechanism for all service capabilities.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/discovery/mechanism The discovery mechanism for the service capabilities shall be predictable from the initial endpoint.

 

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.

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/capabilities
Target type Derived information model, encoding, and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/capabilities/process-offering The service shall provide a process offering capabilities. This capability informs service clients about the available processes.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/capabilities/process-model-identification All process offerings shall provide an identifier for their process model used.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/capabilities/job-control The service shall provide job control and monitoring capabilities. These capabilities enable service clients to manage processing jobs via the service interface.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/capabilities/job-control-per-process-offering The service shall indicate the allowed job control capabilities per process.

 

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.

Abstract process model UML class diagram
Figure : Abstract process model UML class diagram

 

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process
Target type Derived information model, encoding, and software implementation
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process/identifier A process shall provide a unique identifier to distinguish the process from other processes.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process/identifier-string The unique identifier of a process shall be a character string or preferably a resolvable URI.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process/input A process may have an arbitrary number of inputs (zero or more).
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process/input-identifier Each input of a process shall have a unique identifier to distinguish the input from all other inputs.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process/input-identifier-string The unique identifier of an input shall be a character string.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process/input-value-cardinality Each process input shall have a defined cardinality for values.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process/nested-input Process inputs may be nested according to Figure 2 .
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process/nested-input-identifier The identifier of a nested input shall be unique within its nesting node.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process/output A process shall have one or more outputs.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process/output-identifier Each output of a process shall have a unique identifier to distinguish the output from all other outputs of the process.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process/output-identifier-string The unique identifier of an output shall be a character string.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process/output-value-cardinality Each process output shall have a value cardinality of one.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process/nested-output Process outputs may be nested according to Figure 2 .
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process/nested-output-identifier The identifier of a nested output shall be unique within its nesting node.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process/io-format All inputs and outputs that do not serve as nesting parents shall have a defined data format.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process/io-format-properties If inputs and outputs require encoding attributes, these shall be limited to the properties defined in Table 2 .

 

Table 2 – Data encoding properties
Status Definition
mimetype Media type of the data.
encoding Encoding procedure or character set used (e.g. raw, base64, or UTF-8).
schema Identification of the data schema.

 

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.

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/job-control
Target type Derived information model, encoding, and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/capabilities
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/job/identifier The service shall assign a unique identifier to each job.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/job/identifier-unavailable-exception The Service shall return an exception, if the client has attempted to use an invalid job identifier.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/job-control/execution The service shall provide the ability to execute a process, i.e. to create a new job for a given process execution capability. This capability enables service clients to execute the process defined in capabilities.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/job-control/dismiss The service may provide the capability to dismiss a submitted job. This capability enables service clients to indicate that they are no longer interested in the job or its results and permit the server to free the associated resources as soon as possible.

 

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.

Synchronous process execution UML sequence diagram
Figure : 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.

Asynchronous process execution UML sequence diagram
Figure : Asynchronous process execution UML sequence diagram

 

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process-execution
Target type Derived information model, encoding, and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/job-control
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process-execution/select-process The service shall permit a client to determine the process to be executed.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process-execution/process-unavailable-exception The service shall return an exception if the client has attempted to execute an unavailable process.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process-execution/result On successful execution, the service shall deliver a result to the client. This result will contain the output data or a reference to the data.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process-execution/result-expiry The execute result may have an expiration date. After that time the output data will be inaccessible for the client.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process-execution/failed-exception On failed execution, the service shall deliver an exception to the client.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process-execution/input-data The service shall permit a client to specify the input data to be used for a process execution.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process-execution/input-data-exception The service shall return an exception if the client has specified invalid input data for process execution.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process-execution/output-data-format The service shall permit a client to define the desired data exchange format for the results of the process execution, based on the advertised formats for the process offering.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process-execution/output-data-format-exception The service shall return an exception if the client has defined an unsupported data exchange format for the results.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process-execution/mode The service shall provide execution capabilities in synchronous, asynchronous or both modes.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process-execution/mode-per-process-offering The service shall indicate the allowed execution modes per process offering.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process-execution/mode-select In the case of multiple supported execution modes, the WPS server shall permit the client to specify the desired execution mode.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process-execution/mode-auto If the client does not specify the desired execution mode, the service shall automatically pick[3] an appropriate [4] mode out of the supported modes.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process-execution/mode-unavailable-exception The service shall return an exception if the client has specified an unsupported execution mode.

 

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.

Execute call and response “by value” and “by reference” UML sequence diagram
Figure : 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).

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/data-transmission
Target type Derived information model, encoding, and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process-execution
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/data-transmission/input-by-value The service shall accept input data by value.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/data-transmission/input-by-reference The service shall accept input data by reference.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/data-transmission/input-by-reference-unavailable-exception The service shall return an exception, if the given input data reference is inaccessible.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/data-transmission/output-mode The service shall support output data delivery by value, and / or by reference.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/data-transmission/output-mode-per-process-offering The supported output modes shall be specified per process offering.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/data-transmission/output-mode-select In the case of multiple available data transmission modes (by value AND by reference), the Service shall allow a client to specify the desired data-transmission mode for each output.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/data-transmission/output-mode-unavailable-exception The service shall return an exception if the client has specified an unsupported transmission mode.

 

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.

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/job-monitoring
Target type Derived information model, encoding, and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/job-control
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process-execution
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/job-monitoring/status The Service shall provide access to machine-readable status information for asynchronously running jobs.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/job-monitoring/status-set In general, the service shall use the terms of the basic status set (Table 3) describe the current status of a processing job.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/job-monitoring/progress The Service may report the progress of a running job in percent.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/job-monitoring/estimated-completion The Service may provide an estimate when the process results will be available.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/job-monitoring/next-poll The Service may suggest a polling time for the next status check.
Requirement http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/job-monitoring/job-expiry The server may report an expiration time for a job. After this time, a job identifier will become invalid and existing results are removed from the server.

 

Table 3 – Basic status set for jobs
Status Definition
Succeeded The job has finished with no errors.
Failed The job has finished with errors.
Accepted The job is queued for execution. a
Running The job is running. a
a States are only defined for asynchronous execution.

 

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.

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/native-process/model
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/descriptiontype Requirements class for the common description type.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/io-format Requirements class for IO format.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes Requirements class for data types.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/description Requirements class for process description.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile Requirements class for process profile.

 

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.

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

 

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

 

 

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

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

 

Data Description Structure

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

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/native-process/model/io-format
Target type Derived information model, encoding, and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/io-format/structure Format descriptions of process inputs and outputs shall comply with the DataDescription structure defined in Figure 7 and Table 6.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/io-format/default One of the formats defined in the DataDescription structure shall be the default format, i.e. have the attribute “default” set to “true”.

 

DataDescription and supported formats UML class diagram
Figure : DataDescription and supported formats UML class diagram

 

 

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

 

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.

 

I/O data types overview
Figure : I/O data types overview

 

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/model/io-format
Dependency OWS Common 2.0
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/complex-data Requirements class for the complex data.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/literal-data Requirements class for the literal data.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datat-types/bounding-box-data Requirements class for the bounding box data.

 

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.

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/complex-data
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process
Dependency OWS Common 2.0
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/complex-data/description Requirements class for the complex data description.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/complex-data/values Requirements class for the complex data values.

 

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.

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/complex-data/description
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/model/io-format
Dependency OWS Common 2.0
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/complex-data/description/structure The description of valid complex data input and output shall comply with the structure defined in Table 7.

 

Table 7 – ComplexData description properties
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)
Any Placeholder for schema extensions to WPS complex data. Any type. Zero or more (optional)

 

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.

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/complex-data/value
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/complex-data/description
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/complex-data/value/encoding Complex data values must comply with the encoding specified in the complex data description.

 

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
http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/literal-data
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process
Dependency OWS Common 2.0
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/literal-data/description Requirements class for the literal data description.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/literal-data/values Requirements class for the literal data values.

 

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.

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/literal-data/description
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/model/io-format
Dependency OWS Common 2.0
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/literal-data/description/structure 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.

 

LiteralData UML class diagram
Figure : 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

 

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
http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/literal-data/value
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/literal-data/description
Dependency OWS Common 2.0
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/literal-data/value/structure The description of valid literal data values shall comply with the structure defined in Figure 10 and Table 12.

 

LiteralValue UML class diagram
Figure : 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 section 7.3.2.1) will be used.

 

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
http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/bounding-box-data
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process
Dependency OWS Common 2.0
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/bounding-box-data/description Requirements class for the bounding box data description.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/bounding-box-data/values Requirements class for the bounding box data values.

 

BoundingBox Description

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

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

 

BoundingBoxData UML class diagram
Figure : 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”.

 

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
http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/bounding-box-data/values
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/bounding-box-data/description
Dependency OWS Common 2.0
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/bounding-box-data/values/structure The description of bounding box data values shall comply with the structure defined in OWS Common [OGC 06-121r9].
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/bounding-box-data/values/crs The CRS component of the Bounding box values structure shall not be empty.

 

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.

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/native-process/model/description
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/model/description-type
Dependency IETF RFC 4646
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/description/model-compliance The process description shall be in compliance with the WPS process model requirements.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/description/structure A process description shall comply with the structure defined in Figure 12 and Table 15.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/description/language 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 http://www.opengis.net/spec/WPS/2.0/req/native-process/model/description/io-description-type The description of process inputs and outputs shall comply with the structure defined in Figure 12, Table 16, and Table 17.

 

Process UML class diagram
Figure : Process UML class diagram

 

 

Table 15 – The Process structure
Names Definition Data type and values Multiplicity and use
Title Inherited from Table 4
Abstract
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. Input structure, see Table 16. Zero or more (optional)
Output Output items (results) of a process Output structure, see Table 17. One or more (mandatory)

 

Table 16 – Parts of the Input structure
Names Definition Data type and values Multiplicity and use
Title Inherited from Table 4
Abstract
Keywords
Identifier
Metadata
minOccurs a 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)
maxOccurs a Maximum number of times that this parameter may be present Non-negative integer, defaults to “1”. Zero or one
(optional)
DataDescription Data type and domain of this input. A realization of DataDescription, i.e. ComplexData, LiteralData, BoundingBoxData. Zero or one (conditional) b
Input Nested Input. c Input structure, Table 16 (this table). Zero or more (conditional) b
a The minOccurs and maxOccurs parameters have identical semantics to the like-named XML Schema occurrence constraints. b The input shall either include one realization of DataDescription or an arbitrary number of sub-Inputs. c It is recommended to keep the nesting level as low as possible.

 

Table 17 – Parts of the Output structure
Names Definition Data type and values Multiplicity and use
Title Inherited from Table 4
Abstract
Keywords
Identifier
Metadata
DataDescription Data type and domain of this input. A realization of DataDescription, i.e. ComplexData, LiteralData, BoundingBoxData. Zero or one (conditional) a
Output Nested Output. b Output structure, Table 17 (this table). Zero or more (conditional) a
a The output shall either include either one realization of DataDescription or an arbitrary number of sub-Outputs. b It is recommended to keep the nesting level as low as possible.

 

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.

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/concept Requirements class for process concepts.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/generic Requirements class for generic process profiles.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/implementation Requirements class for process implementation profiles.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/inheritance Requirements class for process profile inheritance.

 

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.

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/concept
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/concept/identifier Process concepts are documentation resources with identity. They shall have an identifier that may be referenced by more detailed process definitions.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/concept/content The content of a process concept resource shall eventually lead to the definition of computing processes.

 

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]

 

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/generic
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model/process
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/model/description-type
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/model/description
Dependency IETF RFC 4646
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/generic/structure A process description shall comply with the structure defined in Figure 13 and Table 18.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/generic/description-language 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 http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/generic/io-description-type The description of process inputs and outputs shall comply with the structure defined in Figure 13, Table 19, and Table 20.

 

GenericProcess UML class diagram
Figure : 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 167. Zero or more (optional)
Output Output items (results) of a process GenericOutput structure, see Table 178. 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
minOccurs a 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)
maxOccurs a 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.

 

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.

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/implementation
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/model/process-description
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/implementation/structure A process implementation profile description shall comply with the process description structure defined in http://www.opengis.net/spec/WPS/2.0/req/native-process/model/process-description.

 

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
http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/inheritance
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/concept
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/generic
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/model/description
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/inheritance/hierachy Process profiles may inherit properties from profiles specified at a higher or equal level. The hierarchy is defined in Figure 14.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/inheritance/rules Inheriting process profiles and processes shall obey to the inheritance rules defined in Table 21.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/inheritance/link Links to particular profiles are expressed in the DescriptionType’s metadata element as specified in Table 5.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/inheritance/link-target The links target for profile metadata is the URL of the process profile.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/inheritance/link-role-identifier The link roles defined in Table 22 shall be used to express the hierarchical level of the linked profile.

 

Inheritance hierarchy for process profiles UML class diagram
Figure : 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/O a E/O a
 
Input     E b
  Identifier D I I
  Title D I I
  Keywords D E E
  Abstract D I I
  Metadata D E/O a E/O a
  Multiplicity D R c E d
  Data format   D E d
 
Output     E b
  Identifier D I I
  Title D I I
  Keywords D E E
  Abstract D I I
  Metadata D O O
  Data format   D E d
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

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

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/native-process/xml-encoding
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/model
Dependency OWS Common 2.0
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/xml-encoding/datatypes Requirements class for data type XML encoding.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/xml-encoding/process Requirements class for process description XML encoding.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/xml-encoding/generic-process Requirements class for generic profile XML encoding.

 

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.

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/native-process/xml-encoding/datatypes
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/complex-data
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/literal-data
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/bounding-box-data
Dependency OWS Common 2.0
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/xml-encoding/datatypes/schema The XML encoding of ComplexData, LiteralData, BoundingBoxData and their values shall comply with the XML schema provided by dataTypes.xsd.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/xml-encoding/datatypes/mimetype The mime type for XML encoded literal and bounding box data values shall be “text/xml”.

 

Process Description

This clause specifies the XML encoding for the Process description.

A Process example is listed in Annex B.2.

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/native-process/xml-encoding/process
Target type Derived software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/model/description
Dependency OWS Common 2.0
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/xml-encoding/process/schema An XML encoded Process description shall be a valid XML document of the type wps:Process.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/xml-encoding/process/content The content of the XML encoded Process description shall comply with the content of the information elements defined by the requirements class http://www.opengis.net/spec/WPS/2.0/req/native-process/model/description.

 

Generic Process

This clause specifies the XML encoding for the GenericProcess.

A GenericProcess example is listed in Annex B.3.

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/native-process/xml-encoding/profile/generic-process
Target type Derived software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/profile/generic
Dependency OWS Common 2.0
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/xml-encoding/profile/generic/schema An XML encoded description of a Generic Process shall be a valid XML document of the type wps:GenericProcess.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/xml-encoding/profile/generic/content The content of the XML encoded description of a Generic Process shall comply with the content of the information elements defined by the requirements class http://www.opengis.net/spec/WPS/2.0/req/native-process/model/profile/generic.

 

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.

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/native-process/plain-text-encoding/datatypes
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/complex-data
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/literal-data
Dependency http://www.opengis.net/spec/WPS/2.0/req/native-process/model/datatypes/bounding-box-data
Dependency OWS Common 2.0
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/plain-text-encoding/datatypes/schema The plain text encoding of literal and bounding box values comply with the BNF schema below.
Requirement http://www.opengis.net/spec/WPS/2.0/req/native-process/plain-text-encoding/datatypes/mimetype The mime type for plain text encoded literal and bounding box values shall be “text/plain”.

 


 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.

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/service/model
Target type Software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model
Dependency OWS Common 2.0
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/data-transmission Requirements class for data transmission.
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/handling Requirements class for WPS service handling.
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/process-offering-properties Requirements class for common process offering properties.
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/status-info Requirements class for the status information document.
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/result Requirements class for the processing result document.
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/get-capabilities Requirements class for the GetCapabilities operation.
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/describe-process Requirements class for the DescribeProcess operation.
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/execute Requirements class for the Execute operation.
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/get-status Requirements class for the GetStatus operation.
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/get-result Requirements class for the GetResult operation.

 

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.

Common sequence of WPS operations UML sequence diagram
Figure : Common sequence of WPS operations UML sequence diagram

 

 

Data Transmission

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

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/service/model/data-transmission
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/data-transmission/data The data transmission structures for process inputs and outputs shall comply with the structures defined in Figure 16 , Table 23 , Table 24 , Table 25 , Table 26 , and Table 27 .

 

Input and output data transmission structures UML class diagram
Figure : Input and output data transmission structures UML class diagram

 

 

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

 

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

 

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

 

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

 

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

 

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.

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/service/model/handling
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/handling/request-base All request types of a WPS, except GetCapabilities, shall use the minimum request parameters, defined in [OGC 06-121r9].
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/handling/service For all WPS request types, the service parameter shall have a fixed value of "WPS".
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/handling/version For all WPS request types, the request version parameter shall have a fixed value of "2.0.0".
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/handling/request-base-type All request types of a WPS, except GetCapabilities, shall comply with the request type structure defined in Table 28.

 

Table 28 – Properties of the RequestBaseType
Names Definition Data type and values Multiplicity and use
service Service type identifier Character String, fixed to "WPS" One (mandatory)
version Specification version for operation Character String, fixed to "2.0.0" One or more (mandatory)
Extension Any ancillary information to be sent from client to server. Placeholder for further request parameters defined by WPS extension standards. Any type Zero or more (optional)

 

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

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/service/model/process-offering-properties
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/process-offering-properties/attributes For all process offerings, the attributes defined in Table 29 shall be specified.

 

Table 29 – Parts of the ProcessOfferingPropertiesAttributes structure
Names Definition Data type and values Multiplicity and use
jobControlOptions Job control options supported for this process List of supported options for process control (see Table 30), extensions may introduce additional control options. One or more (mandatory)
outputTransmission Supported transmission modes for output data (by value / by reference) List of supported data transmission options (see Table 31). One or more (mandatory)
processVersion Release version of process (not of WPS specification). May be specified to reflect updates or changes in the process offering. ows:VersionType Zero or one (optional) Include when needed to identify process version. a
processModel Type of the process description HTTP-URI. Value is defined by the process description specification. Defaults to “native”. Zero or one
(conditional) Include when using a different process model than the native process model. b
a The processVersion is informative only. Version negotiation for processVersion is not available. Requests to Execute a process do not include a processVersion identifier.
b This is an extension hook to support processes that have been specified in other OGC Standards, such as SensorML. For those process models, compliance with the WPS abstract process model (section 6.3) has to be ensured.

 

Table 30 – Basic job control options
Option Definition
sync-execute The process offering can/shall be executed synchronously.
async-execute The process offering can/shall be executed asynchronously.

 

Table 31 – Data transmission options
Option Definition
value The data is delivered by value.
reference The data is delivered by reference.

 

StatusInfo Document

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

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/service/model/status-info
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/status-info/document The StatusInfo document shall comply with the structure defined in Table 32 .
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/status-info/document-status The Status element shall contain a well-known identifier for the JobStatus. A basic set has been defined in the WPS conceptual model. WPS operations and WPS extensions may define additional states.
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/status-info/document-status-case-insensitive The content of the Status element shall be treated case insensitive.

 

Table 32 – StatusInfo structure
Names Definition Data type and values Multiplicity and use
JobID Unambiguously identifier of a job within a WPS instance. Character String a One (mandatory)
Status Well-known identifier describing the status of the job. Character String b One (mandatory)
ExpirationDate Date and time by which the job and its results will be no longer accessible. c ISO-8601 date/time string in the form YYYY-MM-DDTHH:MM:SS.SSSZ with T separator character and Z suffix for coordinated universal time (UTC) Zero or one (optional) Include if required.
EstimatedCompletion Date and time by which the processing job will be finished. ISO-8601 date/time string in the form YYYY-MM-DDTHH:MM:SS.SSSZ with T separator character and Z suffix for coordinated universal time (UTC) Zero or one (optional) Include if available.
NextPoll Date and time for the next suggested status polling. ISO-8601 date/time string in the form YYYY-MM-DDTHH:MM:SS.SSSZ with T separator character and Z suffix for coordinated universal time (UTC) Zero or one (optional) Include if required.
PercentCompleted Percentage of process that has been completed. Integer{0..100} d Zero or one (optional) Include if available.
a Particularly suitable JobIDs are UUIDs or monotonic identifiers such as unique timestamps. If the privacy of a Processing Job is imperative, the JobID should be non-guessable.
b The basic status set is defined in Table 3. Additional states may be defined by certain operations or extensions of this standard.
c This element will usually become available when the execution has finished (Status = “finished”).
d Zero (0) means the execution has just started, and 100 means the job is complete. This value is informative only without any accuracy guarantees.

 

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.

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/service/model/result
Target type Derived encoding and software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model
Dependency http://www.opengis.net/spec/WPS/2.0/req/service/model/data-transmission
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/result/document The Result document shall comply with the structure defined in Table 33 .

 

Table 33 – Result structure
Names Definition Data type and values Multiplicity and use
JobID Unambiguously identifier of a job within a WPS instance. Character String a Zero or one
(conditional) b
ExpirationDate Date and time by which the results will be no longer accessible. c ISO-8601 date/time string in the form YYYY-MM-DDTHH:MM:SS.SSSZ with T separator character and Z suffix for coordinated universal time (UTC) Zero or one (conditional) Include if required, i.e. if the server will delete stored results at some point in time.
Output Output item returned by a process execution. DataOutputType structure, see Table 37. One or more (mandatory)
a Particularly suitable JobIDs are UUIDs or monotonic identifiers such as unique timestamps. If the privacy of a Processing Job is imperative, the JobID should be non-guessable. In asynchronous execution, the JobID would be shared among related StatusInfo and Result documents.
b Include if required, e.g. in a response to an asynchronous execution.
c For results delivered “by reference” this element may indicate when the Data Outputs will be deleted by the server.

 

Table 34 – Parts of the DataOutputType structure
Names Definition Data type and values Multiplicity and use
id Unambiguous identifier or name of an output item. URI One (mandatory)
Data The data provided by this output item.   Zero or one (conditional) a
Output Nested output, child element. DataOutputType structure, see Table 34 (this table) Zero or one (conditional) a
a One and only one of these items shall be included.

 

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.

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/service/model/get-capabilities
Target type Software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model
Dependency OWS Common 2.0
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/get-capabilities/request Requirements class for the GetCapabilities request.
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/get-capabilities/response Requirements class for the GetCapabilities response.
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/get-capabilities/exception Requirements class for GetCapabilities operation exceptions.

 

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 request UML class diagram
Figure : GetCapabilities request UML class diagram

 

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/service/model/get-capabilities/request
Target type Software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model
Dependency OWS Common 2.0
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/get-capabilities/request/ows The GetCapabilities operation request shall be implemented as specified in Clause 7 of OWS Common [OGC 06-121r9].
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/get-capabilities/request/accept-versions If the AcceptVersions parameter is contained in the request, it shall contain the character string “2.0.0”.
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/get-capabilities/request/properties 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)

 

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.

Capabilities document UML class diagram
Figure : Capabilities document UML class diagram

 

 

Requirements Class
http://www.opengis.net/spec/WPS/2.0/req/service/model/get-capabilities/response
Target type Software implementation
Dependency http://www.opengis.net/spec/WPS/2.0/req/conceptual-model
Dependency OWS Common 2.0
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/get-capabilities/response/ows The capabilities response shall provide service metadata according to [OGC 06-121r9], clause 7.4.2.
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/get-capabilities/response/version The default version of the Capabilities document returned by a service implementing this standard shall be “2.0.0”.
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/get-capabilities/response/properties In addition to the properties inherited from OWS Common OWSServiceMetadata, the WPS Capabilities shall include the properties according to Table 36 .
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/get-capabilities/response/process-summary The contents section of the Capabilities document shall contain a process summary for each of the process offerings.
Requirement http://www.opengis.net/spec/WPS/2.0/req/service/model/get-capabilities/response/process-summary-properties 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 (ma