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 |
1. Scope
This document specifies the interface to a general purpose Web Processing Service (WPS). A WPS is a web service that enables the execution of computing processes and the retrieval of metadata describing their purpose and functionality. Typically, these processes combine raster, vector, and/or coverage data with well-defined algorithms to produce new raster, vector, and/or coverage information.
The WPS protocol supports both synchronous and asynchronous execution of processes. Synchronous execution may be used in simple and quick computation scenarios, where the data processing takes little to almost no time. Asynchronous processing is particularly well suited for complex computation scenarios which may take significant time.
The specification uses a core and extensions model to organize its features:
- A core conceptual model, defining basic requirements for a web based processing service,
- A process model to support the description and discovery of processes on the web,
- A basic data model that supports arbitrary (standard or non-standard) data formats for inputs and outputs,
- A WPS service model and encoding based on OGC baseline standards, and
- A Dismiss extension to allow clients to terminate asynchronous processing jobs.
2. Conformance
Conformance with this standard shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site[1].
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 |
3. 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.
4. 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).
5. 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.
5.1 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
5.3 UML Notation
Unified Modeling Language (UML) static structure diagrams appearing in this specification are used as described in section 5.2 of OGC06-121r9. Further, the following conventions hold:
- 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.
5.4 Namespace Conventions
The following namespaces are used in this document. The prefix abbreviations used constitute conventions used here, but are not normative. The namespaces to which the prefixes refer are normative, however.
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 |
6. 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).
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. |
6.1 Service Discovery
Any WPS server shall be self-contained, i.e. provide an initial endpoint that can be used by a WPS client to determine the server’s capabilities.
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. |
6.2 Service Capabilities
The basic capabilities of any WPS server fall into two categories: The first category comprises capabilities for process discovery and retrieval of process descriptions. The second category comprises capabilities to manage and monitor processing jobs.
Since the processes provided by a WPS server may have different degrees of complexity, the server shall indicate the allowed job control capabilities mode per process offering.
Further service capabilities, i.e. for secure communication and user authentication may be provided with the service but are neither covered nor restricted by this specification as long as they do not alter or change the semantics of other job control capabilities.
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. |
6.3 Abstract Process Model
The abstract process model specifies generic requirements for process offerings that can be used in conjunction with WPS. Processes, as well as their inputs and outputs, are elements with identity. A process input may have arbitrarily defined value cardinality, i.e. for a given input, multiple datasets may be submitted for execution. A process output always has a value cardinality of one. Process inputs and outputs may also be nested. Identifiers for inputs and outputs shall be unique. For nested children it is sufficient to have a unique nesting path. Any input and output that does not have child elements shall have a defined data type so that a client is aware of the valid data formats for process execution.
The abstract process model provides many degrees of freedom for process descriptions. However, it does not enforce additional complexity for very simple processes.
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 . |
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. |
6.4 Job Control
The execution capability, that permits WPS clients to instantiate and run processing jobs, is the most prominent job control capability. Furthermore, the ability to dismiss or delete a job is useful for long-running processes in order to release server resources.
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. |
6.5 Process Execution
Process executions on a WPS server may be run either synchronously (Figure 3) or asynchronously (see Figure 4). Synchronous execution is a suitable approach for jobs that take a relatively short time[2] to complete. Asynchronous execution is preferable for jobs that may take a long time to complete.
In the synchronous case, a WPS client submits an execute request to the WPS server and keeps listening for a response until the processing job has completed and the processing result has been returned. This requires a persistent connection between client and server.
In the asynchronous case, the client sends an execute request to the WPS server and immediately receives a status information response. This information confirms that the request was received and accepted by the server and that a processing job has been created and will be run in the future. The status information response also contains a processing job identifier that is used by the client when checking to see if execution has completed. (The client may also manage the processing job using available steering capabilities.) In addition, the status information response contains the result location, i.e. the URL where the processing result can be found after the processing job has completed.
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. |
6.6 Data Transmission by Value and by Reference
Data exchange between WPS clients and servers requires an agreement on the general data exchange patterns and suitable communication protocols. This specification defines two general data transmission modes for data exchange between WPS client and server.
Clients may send input data to or receive output data from a process in two distinct ways: (1) by reference, and (2) by value (see Figure 5). For brevity, this figure only shows the transmission patterns in the pure form, i.e. the same pattern is used for all inputs and outputs. However, mixed patterns are possible. Typically, small or atomic data such as integers, doubles or short strings are submitted by value. Large data inputs (outputs) are usually supplied by reference.
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. |
6.7 Job Monitoring
By definition, a processing job is a server-side object created by a processing service in response for a particular process execution. It is comprised of a process definition (i.e. one of the process offerings defined in the WPS server’s capabilities), the input data provided or specified by the WPS client, and the outputs that are eventually delivered when the job has been completed.
Since the processing job is a server-side object, a WPS client has no means to inspect the status of a job on its own. Therefore, the server should provide a unique identifier for each job. For privacy, it is recommended to keep this identifier confidential between client and server.
For jobs running in asynchronous mode, the WPS server shall also provide monitoring information and it may also contain estimates on the completion time or additional elements related to status polling.
If a client finds a polling time in the status information, it shall respect it and behave accordingly. The service may rely on the client polling roughly around this time to obtain updated status information.
If a client finds an expiry date in the status information, it shall respect it and behave accordingly, i.e. ensure that the execution result is evaluated on time and the outputs are retrieved before the job is removed from the server. This requirement allows for robust WPS implementations and the timely re-allocation of server resources.
This section also defines a basic status set to communicate the status of a server-side job to the client. Extensions of this specification may introduce additional states for fine-grained monitoring or domain-specific purposes.
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. |
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. |
7. 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:
- A general structure for process interface descriptions (sections 7.1, 7.4) that support process discovery and cataloging
- A set of data types to submit and receive data during process execution (sections 7.2, 7.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. |
7.1 Common Description Type
Descriptive elements of processes, inputs and outputs are derived from the BasicIdentificationType provided by OWS Common (Figure 6). Other descriptive information shall be recorded in the Metadata element in the form of simple links with an appropriate role identifier.
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”. |
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. |
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) |
7.2 Data Description Structure
The DataDescription structure contains basic properties for defining data inputs and outputs, including mimetype, encoding and schema. These properties specify supported formats for input and output data of computing processes. Any input or output item may support multiple formats, one of which is the default format. Processes may require that an input or output data set does not exceed a certain data volume.
Requirements Class | |
---|---|
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”. |
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”. |
7.3 Data Types
This specification defines three common data types for process input and output data (Figure 8):
- 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.
- LiteralData, defined as a value with an optional unit.
- BoundingBoxData, defined as a minimum bounding rectangle in geographic coordinates.
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. |
7.3.1 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. |
7.3.1.1 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. |
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) |
7.3.1.2 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. |
7.3.2 Literal Data
The LiteralData type encodes atomic data such as scalars, linear units, or well-known names. Domains for LiteralData are a combination of data types (e.g. Double, Integer, String), a given value range, and an associated unit (e.g. meters, degrees Celsius).
Requirements Class | |
---|---|
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. |
7.3.2.1 LiteralData Description
The LiteralData description structure inherits essential elements from ows:DomainType allowing it to specify value domains including Units of Measure and Default Values. It restricts ows:DomainType by forbidding:
- “NoValues” for a particular domain
- 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. |
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) |
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”. |
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. |
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 |
7.3.2.2 LiteralData Values
LiteralData values represent values that correspond to a particular domain defined in the LiteralData structure. Figure 10 shows the mapping from the LiteralValue structure to the corresponding elements in the LiteralDataDescriptionType.
Requirements Class | |
---|---|
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. |
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. |
7.3.3 BoundingBox Data
Bounding box data serves a variety of purposes in spatial data processing. Some simple applications are the definition of extents for a clipping operation or the definition of an analysis region. This specification inherits the bounding box specification from OWS Common.
Requirements Class | |
---|---|
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. |
7.3.3.1 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. |
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) |
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”. |
7.3.3.2 BoundingBox Values
Values for bounding boxes are specified in the BoundingBox data type from OWS Common [OGC 06-121r9]. For consistency with the BoundingBoxData description, the specification of a CRS is mandatory.
Requirements Class | |
---|---|
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. |
7.4 Process Description
This section defines information structures that describe a process. It includes elements that link to documentation resources on the behavior and mechanics of a process as well as descriptive elements about its inputs and outputs. The process description model realizes and extends the requirements defined in the abstract process model in 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. |
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) |
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. |
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. |
7.5 Process Profiles
Process profiles are blueprints for process implementations and are meant to harmonize process implementations to a certain degree. They serve as a reference for process implementations by providing a description of what the process actually does. While this specification does not attempt to enforce or suggest any particular process profiles, it provides a mechanism to define common processing functionality within the scope of WPS, thus supporting basic process cataloguing and retrieval tasks for distributed processing infrastructures. Depending on the degree of harmonization, the definitions of process profiles may be used to foster a common understanding of widely used processing functions. However, they may also be used to harmonize the technical details of process interfaces and thus document particular interoperability arrangements between process providers and consumers.
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. |
7.5.1 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. |
7.5.2 Generic Process Profile
A generic profile is the abstract interface of a process. It provides a detailed description of the process mechanics and declares a signature for process inputs and outputs. The generic profile consists of a unique identifier and a generalized process description. This is similar to a process description as defined in clause 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. |
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) |
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. |
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. |
7.5.3 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. |
7.5.4 Profile Inheritance
The hierarchical structure allows for inheritance between different types of profiles (see Figure 14). The definition and use of generic profiles for commonly used processing functions is generally recommended. However, there might be use cases for a product-specific harmonization of process interfaces. In this case, an implementation profile may be directly derived from a concept or defined in isolation.
If a profile in the hierarchy is derived from another profile at an equal or higher level, it must respect the inheritance rules given in Table 21. These rules ensure consistency in the use of identifiers, the specification of inputs and outputs as well as compliance to the behavior of the declared parent profiles.
Processes and process profiles may use metadata links to indicate compliance to a particular process profile. Links to particular profiles shall be embedded in the process’ metadata elements. The reserved role identifiers for the different profile levels are listed in Table 22.
An example which illustrates the inheritance rules for process profiles is given in annex B.10.
Requirements Class | |
---|---|
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. |
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. |
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 |
8. WPS Native Process Model Encoding
8.1 XML Schema Implementation
This section specifies the XML encoding of the elements of the WPS native process model. The referred XML schema elements are provided by the associated schema package delivered with this standard and located at http://schemas.opengis.net/wps/2.0/.
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. |
8.1.1 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”. |
8.1.2 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. |
8.1.3 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. |
8.2 Plain Text Encoding for LiteralData and BoundingBoxData Values
This clause specifies the plain text encoding of data types for literal and bounding box data values.
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
9. 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. |
9.1 Overview of WPS Core Operations
The WPS interface specified in this section supports retrieval and execution of processes for geospatial computation. For that purpose, the WPS service model specifies the following operations that may be invoked by a WPS client and performed by a WPS server[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.
9.2 Data Transmission
Data exchange between WPS clients and servers requires an agreement on the general data exchange patterns and suitable communication protocols. Data may be sent to (received from) a WPS in two distinct ways: (1) by reference (using HTTP/GET or HTTP/POST), and (2) by value. Clients may send input data in either fashion. Output data may be requested in any fashion declared by the data transmission options defined for the process offering. Typically, large data inputs and outputs are delivered by reference.
Requirements Class | |
---|---|
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 . |
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. |
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. |
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) |
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. |
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) |
9.3 WPS Service Handling
The WPS service model seeks compliance with OWS Common and implements the baseline communication protocol for OWS services and the related information elements defined in [OGC 06-121r9], clause 9.2.1.
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. |
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) |
9.4 Process Offering
A process offering structure contains information about the processes that may be run on a WPS server. Furthermore, the process offerings structure contains properties that describe the available execution modes of a process, the allowed data transmission modes, its version, and the process type (if it deviates from the native process model).
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. |
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. |
Option | Definition |
---|---|
sync-execute | The process offering can/shall be executed synchronously. |
async-execute | The process offering can/shall be executed asynchronously. |
Option | Definition |
---|---|
value | The data is delivered by value. |
reference | The data is delivered by reference. |
9.5 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. |
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. |
9.6 Result Document
A Result document is a structure that contains the results of a process execution. It is a shared element between the Execute and GetResult operations.
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 . |
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. |
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. |
9.7 GetCapabilities Operation
Per OGC 06-121r9, a GetCapabilities operation is required for any OGC Web service. For WPS, this operation allows a client to retrieve service metadata, basic process offerings, and the available processes present on a WPS server.
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. |
9.7.1 GetCapabilities Request
The GetCapabilities request is mandatory for any OGC service. Figure 17 shows how the GetCapabilities request for a WPS relates to the generic GetCapabilitiesType defined by OWS Common. An Extension element provides a hook for further request parameters that may be defined by WPS extension specifications.
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 . |
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) |
9.7.2 GetCapabilities Response
The response to a GetCapabilities operation is a document describing the service’s capabilities. Figure 18 shows how the WPS Capabilities are derived from the CapabilitiesBaseType defined in [OGC 06-121r9]. The OperationsMetadata element lists the request types supported by a WPS server. The contents section delivers information about the process offerings of the server. An Extension element provides a hook for additional service capabilities that cannot be covered by other available elements.
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 . |
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 |