4.1.  Terms and definitions

A resource that may be available as one or more sub-resource distributions that conform to one or more OGC API standards. (OGC API — Common — Part 2: Geospatial Data)

A resource accessible at the OGC API path /collections/{collectionId} that provides metadata about a collection.

A collection of data, published or curated by a single agent, and available for access or download in one or more representations. (Data Catalog Vocabulary (DCAT) — Version 2)

A specific representation of a dataset. A dataset might be available in multiple serializations that may differ in various ways, including natural language, media-type or format, schematic organization, temporal and spatial resolution, level of detail or profiles (which might specify any or all of the above). (Data Catalog Vocabulary (DCAT) — Version 2)

EXAMPLE: a downloadable file, an RSS feed or an API.

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.

JavaScript Object Notation is a lightweight data-interchange format. JSON is easy for humans to read and write and it is easy for machines to parse and generate.

The term “link” is commonly used as substitute for URL or URI. In this Standard, “link” refers to an element described by the schema for a link as shown at link.yaml. This is a JSON element containing properties such as “rel” (relation) and “href”. The value of the “href” property is an URI.

HTTP Link header, as defined in RFC 8288 (Web Linking).

A collection that is local to the OGC API deployment currently being accessed.

A method or procedure, that conforms to an OGC API Standard, used to control how users or systems can access and interact with data.

EXAMPLE: OGC API — Tiles — Part 1: Core, OGC API — Coverages — Part 1: Core, OGC API — Discrete Global Grid Systems — Part 1: Core, OGC API — Features — Part 1: Core, OGC API — Environmental Data Retrieval Standard, OGC API — Maps — Part 1: Core

An implementation of an OGC API Standard that is accessible to users and other system typically through the internet.

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. In this Standard, 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.

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

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.

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

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

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

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

A process output with identifier {outputID} that is explicitly specified in the “outputs” section of an execute request.

A process output that is defined in the description of a process and is generated as a result of an execute request where the “outputs” parameter has been omitted. Omitting the “outputs” parameters of an execute request is equivalent to explicitly requesting all of the outputs defined in the process description

A collection that is not local to the OGC API deployment currently being accessed.

The Representational State Transfer (REST) style is an abstraction of the architectural elements within a distributed hypermedia system. REST focuses on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements. It encompasses the fundamental constraints upon components, connectors, and data that define the basis of the Web architecture, and thus the essence of its behavior as a network-based application. An API that conforms to the REST architectural principles/constraints is called a RESTful API. (Source: OGC 18-088)

4.2.  Abbreviated terms

5.1.  Identifiers

The normative provisions in this Standard are denoted by the URI

http://www.opengis.net/spec/ogcapi-processes-1/1.0

All requirements, permission, recommendations, and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.

5.2.  APIs

This Standard is primarily concerned with defining the components of a Processes API. That is an API that enables the execution of computing processes, the retrieval of metadata describing their purpose and functionality and the retrieval of the results of the process execution. The reader, however, should be cogniscant of the fact that an implementation of the Processes API as defined in this Standard may be embeded as part of a broader API. For example, a single server may implement the Features and Processes APIs and so common elements (such as the landing page) will contain components of both standards. When the term “API” is encountered in this Standard, the term is in most cases referring only to the components of a Processes API even though an implementation of the Processes API may be part of a broader API implementation.

5.3.  Schemas

Schemas defined in this Standard are defined using the JSON Schema standard and are encoded using YAML which is a human-friendly data serialization language.

5.4.  Link relations

To express relationships between resources, RFC 8288 (Web Linking) is used.

The following link relation types are used in this document.

In addition, the following link relation types are used for which no applicable registered link relation type could be identified.

Each resource representation includes an array of links. Implementations are free to add additional links for all resources provided by an implementation of the Processes API.

5.5.  Use of HTTPS

For simplicity, this Standard only refers to the HTTP protocol. This is not meant to exclude the use of HTTPS. This is simply a shorthand notation for “HTTP or HTTPS”. In fact, most servers are expected to use HTTPS, not HTTP.

OGC Web API Standards do not prohibit the use of any valid HTTP option. However, implementers should be aware that optional capabilities which are not in common use could be an impediment to interoperability.

5.6.  HTTP URIs

This Standard does not restrict the lexical space of URIs used in an implementation of the Processes API beyond the requirements of the HTTP and URI Syntax IETF RFCs. If URIs include reserved characters that are delimiters in the URI subcomponent, these must be percent-encoded. See Clause 2 of RFC 3986 (URI Syntax) for details.

6.1.  Encodings

JSON is the encoding for requests and responses. The inputs and outputs of a process can be in any format. The formats are defined at the time of job creation and are fixed for the specific job.

Support for HTML is recommended as HTML is the core language of the World Wide Web. A server that supports HTML will support browsing with a web browser and will enable search engines to crawl and index the processes.

7.1.  Overview

A server that implements the OGC API — Processes Standard provides access to processes.

Each implementation of the OGC API — Processes Standard has a single LandingPage (path /) that provides links to:

Note that additional requirements classes may introduce additional links for inclusion in the landing page.

The APIDefinition describes the capabilities of the server that can be used by clients to connect to the server or by development tools to support the implementation of servers and clients. Accessing the APIDefinition using HTTP GET returns a description of the an API that includes the Processes API defined in this Standard but may include the description of additional components that are part of a broader containing API.

Accessing Conformance using HTTP GET returns a list of URIs of conformance classes implemented by the server.

The list of processes contains a summary of each process offered by the OGC API — Processes implementation, including the link to a more detailed description of the process.

The process description contains information about inputs and outputs and a link to the execution-endpoint for the process.

A HTTP POST request to the execution-endpoint creates a new job. The inputs and outputs need to be passed in a JSON execute-request.

The URL for accessing status information is delivered in the HTTP header location.

After a process is finished (status = successful/failed), the results/exceptions can be retrieved.

Figure 1 — Resources in the Core requirements class

The OGC API — Processes Standard utilizes elements of the OGC API-Common Standard. Table 9 Identifies the API-Common Requirements Classes which are applicable to each section of this Processes API Standard.

Table 9 — Mapping API — Processes Sections to API-Common Requirements Classes

7.2.  Retrieve the API landing page

The following section defines the requirements to retrieve an API landing page that contains links to Processes API resources but may also contain links to resources that are part of a broader, containing, API.

type: object
required:
  - links
properties:
  title:
    type: string
    example: Example processing server
  description:
    type: string
    example: Example server implementing the OGC API - Processes 1.0 Standard
  attribution:
    type: string
    title: attribution for the Processes API
    description: The `attribution` should be short and intended for presentation to a user, for example, in a corner of a map. Parts of the text can be links to other resources if additional information is needed. The string can include HTML markup.
  links:
    type: array
    items:
      $ref: 'link.yaml'

type: object
required:
  - href
properties:
  href:
    type: string
  rel:
    type: string
    example: service
  type:
    type: string
    example: application/json
  hreflang:
    type: string
    example: en
  title:
    type: string
  profile:
    type: array
    description:
      One or more identifiers that provide information about additional
      semantics (constraints, conventions, extensions), in addition to
      those defined by the media type, that are associated with the
      target resource.
    items:
      type: string

{
  "links": [{
    "href": "http://processing.example.org/oapi-p?f=application/json",
    "rel": "self",
    "type": "application/json",
    "title": "This document"
  },{
    "href": "http://processing.example.org/oapi-p?f=text/html",
    "rel": "alternate",
    "type": "text/html",
    "title": "This document as HTML"
  },
  {
    "href": "http://processing.example.org/oapi-p/api?f=application/json",
    "rel": "service-desc",
    "type": "application/json",
    "title": "API definition for this endpoint as JSON"
  },
  {
    "href": "http://processing.example.org/oapi-p/api?f=text/html",
    "rel": "service-desc",
    "type": "text/html",
    "title": "API definition for this endpoint as HTML"
  },
  {
    "href": "http://processing.example.org/oapi-p/conformance",
    "rel": "http://www.opengis.net/def/rel/ogc/1.0/conformance",
    "type": "application/json",
    "title": "OGC API - Processes conformance classes implemented by this server"
  },
  {
    "href": "http://processing.example.org/oapi-p/processes",
    "rel": "http://www.opengis.net/def/rel/ogc/1.0/processes",
    "type": "application/json",
    "title": "Metadata about the processes"
  },
  {
    "href": "http://processing.example.org/oapi-p/jobs",
    "rel": "http://www.opengis.net/def/rel/ogc/1.0/job-list",
    "title": "The endpoint for job monitoring"
  }]
}

7.3.  Retrieve an API definition

The following section defines the requirements to retrieve an API definition. This API may only implement components of the Processes API defined in this Standard but may define the implementation of a broader API into which the Processes API is embedded.

7.4.  Declaration of conformance classes

type: object
required:
  - conformsTo
properties:
  conformsTo:
    type: array
    items:
      type: string
      example: "http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/core"

{
  "conformsTo": [
    "http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/core",
    "http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/json",
    "http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/html",
    "http://www.opengis.net/spec/ogcapi-processes-1/1.0/conf/oas30"
  ]
}

7.5.  Use of HTTP 1.1

This include the correct use of status codes, headers. etc.

Supporting the method HEAD in addition to GET can be useful for clients and is simple to implement. In particular, the HEAD method is useful in determining the size of a potential response.

Servers implementing Cross-Origin Resource Sharing (CORS) will also implement the OPTIONS method.

7.6.  Support for cross-origin requests

Access to content from a HTML page is by default prohibited for security reasons if the content is located on another host than the webpage (“same-origin policy”). Cross-origin resource sharing is a mechanism that allows restricted resources on a web page to be requested from another domain outside the domain from which the first resource was served. A typical example is a web-application accessing processes and data from multiple servers.

Two common mechanisms to support cross-origin requests are:

7.7.  Content negotiation by profile

The use of generic media types such as application/json makes it difficult to request or identify different flavors or profiles of a resource. For example, the media type application/json could be used to describe an OGC process description document as well as an OpenEO process description document.

It would thus be useful if there was a mechanism for requesting a profile of a resource. Although there is a new HTTP header, Accept-Profile, that is to be defined in an upcoming Internet-Draft there is currently no standardzied was to request a profile of a resource. Existing standards, however, do provide mechanisms for specifying profile information in HTTP headers. Specifically (see Content Negotiation by Profile) profiles of a resource may be requested by:

This standard also defines a query paramete, profile, that may be used with an HTTP GET request to specify one or more profiles of a resource that are to be retrieved.

7.8.  Limit parameter

Several resources defined in this Standard (see Retrieve a process list, Retrieve a job list) use the limit parameter to control the maximum number of results that are presented in a response page.

As an example, using the default/maximum values of 10/1000 from the OpenAPI fragment in requirement /req/core/pl-limit-definition or /req/job-list/limit-definition:

This Standard provides requirements and recommendations about links in general and the next link in particular at the appropriate resource end points.

This Stadard does not mandate any specific implementation approach for the next links.

An implementation of the Processes API could use opaque links that are managed by the server. It is up to the server to determine how long these links can be dereferenced. Clients should be prepared to receive a 404 response.

Another implementation approach is to use an implementation-specific parameter that specifies the index within the result set from which the server begins presenting results in the response, like offset or the startIndex parameter that was used in WFS 2.0.

An implementation of the Processes API will return no next link, if all selected results have been returned, and the server knows for certain that there are no further results to be presented. However, in some cases, the server may not be aware that it has already returned all selected results. For example, if the request states limit=10 and the query to the backend returns exactly 10 results. The server may not know if there are more results or not (in most cases there will be more results), unless the total number of results is also computed, which may be too costly. The server will then prudently add the next link, and if there are no more results, dereferencing the next link will return an empty results list and no next link. This behavior is consistent with the statements above.

Clients should not assume that paging is safe against changes to the dataset being accesses while a client iterates through next links. If a server provides opaque links these could be safe and maintain the state during the original request. Using a parameter for the start index, however, will not be safe.

This Standard also has recommendations about including a prev link at the appropriate resource end points. Providing prev links supports navigating back and forth between pages, but depending on the implementation approach, it may be too complex to implement.

7.9.  Link headers

7.10.  Retrieve a process list

The following section defines the requirements to retrieve the available processes offered by an implmentation of the Processes API.

It should be noted that the number of processes exposed via the Processes API may be very different than the number of processes offer by a back-end system upon which the Processes API is implemented.

name: limit
in: query
required: false
schema:
  type: integer
  minimum: 1
  maximum: 10000
  default: 10
style: form
explode: false

type: object
required:
  - processes
  - links
properties:
  processes:
    type: array
    items:
      $ref: "processSummary.yaml"
  links:
    type: array
    items:
      $ref: "../common-core/link.yaml"

allOf:
  - $ref: "descriptionType.yaml"
  - type: object
    required:
      - id
      - version
    properties:
      id:
        type: string
      version:
        type: string
      jobControlOptions:
        type: array
        items:
          $ref: "jobControlOptions.yaml"
      links:
        type: array
        items:
          $ref: "../common-core/link.yaml"

type: string
enum:
  - sync-execute
  - async-execute
  - dismiss

GET /processes HTTP/1.1
Host: processing.example.org

{
  "processes": [
    {
      "id": "EchoProcess",
      "title": "EchoProcess",
      "version": "1.0.0",
      "jobControlOptions": [
        "async-execute",
        "sync-execute"
      ],
      "links": [
        {
          "href": "https://processing.example.org/oapi-p/processes/EchoProcess",
          "type": "application/json",
          "rel": "self",
          "title": "process description"
        }
      ]
    }
  ],
  "links": [
    {
      "href": "https://processing.example.org/oapi-p/processes?f=json",
      "rel": "self",
      "type": "application/json"
    },
    {
      "href": "https://processing.example.org/oapi-p/processes?f=html",
      "rel": "alternate",
      "type": "text/html"
    }
  ]
}

7.11.  Retrieve a process description

The following section defines the requirements to retrieve metadata about a process.

7.12.  Execute a process

This section describes the requirements for executing a process.

Depending on the description of the process and the negotiated process execution mode, process execution may result in the creation of a job resource.

type: object
properties:
  processID:
    type: string
    format: uri
  inputs:
    additionalProperties:
      $ref: "input.yaml"
  outputs:
    additionalProperties:
      $ref: "output.yaml"
  subscriber:
    $ref: "subscriber.yaml"

oneOf:
  - $ref: "inputValueNoObject.yaml"
  - $ref: "qualifiedInputValue.yaml"
  - $ref: "../common-core/link.yaml"

type: object
properties:
  format:
    $ref: "format.yaml"

type: object
properties:
  mediaType:
    type: string
  encoding:
    type: string
  schema:
    oneOf:
      - type: string
        format: url
      - type: object

"inputs": {
   "inputName1": <input value 1>,
   "inputName2": <input value 2>,
   etc.
}

anyOf:
  - type: string
  - type: number
  - type: integer
  - type: boolean
  - type: array
    items:
      $ref: "inputValue.yaml"
  - $ref: "binaryInputValue.yaml"
  - $ref: "bbox.yaml"
  - $ref: "collectionInput.yaml"

"stringInput": "String value"

"dateInput": "2021-05-24T20:40:13-05:00"

"numberInput": 3.14159

"integerInput": 10

"booleanInput": true

"arrayOfSimpleValues": [1, 2, 4, 10, 7]

"arrayOfSimpleValues": ["a"]

"arrayOfArrays": [[1,2,3,4], ["a","b","c","d"]]

"arrayOfQualifiedValues": [
  {
    "value": {
      "measurement": 10.3,
      "uom": "m",
      "reference": "https://ucum.org/ucum-essence.xml"
    }
  },
  {
    "value": {
      "measurement": 10.5,
      "uom": "m",
      "reference": "https://ucum.org/ucum-essence.xml"
    }
  },
  {
    "value": {
      "measurement": 10.9,
      "uom": "m",
      "reference": "https://ucum.org/ucum-essence.xml"
    }
  },...
],

allOf:
  - $ref: "format.yaml"
  - type: object
    required:
      - value
    properties:
      value:
        $ref: "inputValue.yaml"

anyOf:
  - $ref: "inputValueNoObject.yaml"
  - type: object

"complexObjectInput": {
  "value": {
    "property1": "value1",
    "property2": "value2",
    "property3": "value3"
  }
}

"geometryInput": {
  "title": "Geometry input",
  "description": "This is an example of a geometry input.  In this case the geometry can be expressed as a GML or GeoJSON geometry.",
  "minOccurs": 2,
  "maxOccurs": 5,
  "schema": {
    "oneOf": [
      {
        "type": "string",
        "contentMediaType": "application/gml+xml; version=3.2",
        "contentSchema": "http://schemas.opengis.net/gml/3.2.1/geometryBasic2d.xsd"
      },
      {
        "$ref": "http://schemas.opengis.net/ogcapi/features/part1/1.0/openapi/schemas/geometryGeoJSON.json"
      }
    ]
  }
},

"geometryInputs": [
  {
    "value": "<gml:Polygon gml:id=\"GID1\" srsName=\"urn:ogc:def:crs:OGC::CRS84\"><gml:exterior><gml:LinearRing><gml:posList>-77.024519 38.810529 -77.024635 38.810973 -77.024704 38.810962 -77.024776 38.811239 -77.024957 38.81121 -77.024905 38.811012 -77.024905 38.811012 -77.024865 38.810857 -77.025024 38.810832 -77.025071 38.811012 -77.025203 38.810992 -77.02506 38.810444 -77.024519 38.810529</gml:posList></gml:LinearRing></gml:exterior></gml:Polygon>",
    "mediaType": "application/gml+xml; version=3.2"
  },
  {
    "value": {
      "type": "Polygon",
      "coordinates": [[[ -176.5814819, -44.10896301 ],
                       [ -176.5818024, -44.10964584 ],
                       [ -176.5844116, -44.11236572 ],
                       [ -176.5935974, -44.11021805 ],
                       [ -176.5973511, -44.10743332 ],
                       [ -176.5950928, -44.10562134 ],
                       [ -176.5858459, -44.1043396  ],
                       [ -176.5811157, -44.10667801 ],
                       [ -176.5814819, -44.10896301 ]]]
    },
    "mediaType": "application/geo+json"
  }
]

type: string
format: byte

"schema": {
  "type": "string",
  "contentEncoding": "binary",
  "contentMediaType": "image/tiff; application=geotiff"
}

"imageInput": "R0lGODdhNAHCAfcAAAcHDD+Gs4sLDQpDaqGFdaHE54dJPEoECUlGRteKgcdITgokG4hoVkpY\ngNzHwKKkqOLm7RRjlEgpHU9iZ44lHQYqVdmki6doVmhHOMOIeJG20HiDjCcKBglIeadISrso\nJGooFNbN2d2qr8aljyklHwQJQkdvkWaKxIdrb442LidLeGhMTp6LkeP1+Kh3aiUuVAoUHmlu\ngkcwNYdZRmkJDYGcsDFokElVYyk1NsWWhLEPDtmQldrUyoyFhrjo+Nna5d+4tMGstspoXgc4\n...qgu7sSu7qbtCs2u7t6u6rLsrp4u7veu76eO6vyu8w0u8xWu8x4u8yau8shu8y+u8zwu90Su9\n00u91Wu914u92au928u9whsQADs="

"schema": {
  "oneOf": [
    {
      "type": "string",
      "contentEncoding": "binary",
      "contentMediaType": "image/tiff; application=geotiff"
    },
    {
      "type": "string",
      "contentEncoding": "binary",
      "contentMediaType": "image/jp2"
    }
  ]
}

{
  "value": "VBORw0KGgoAAAANSUhEUgAABvwAAAa4CAYAAABMB35kAAABhGlDQ1BJQ0MgcHJvZmlsZQAA\nKJF9kT1Iw0AcxV9TpSL1A+xQxCFDdbIgKuKoVShChVArtOpgcumH0KQhSXFxFFwLDn4sVh1c\nnHV1cBUEwQ8QNzcnRRcp8X9JoUWMB8f9eHfvcfcOEOplplkdY4Cm22Y6mRCzuRUx9IogouhH\n ... \nj3Z5mX7/PCPVRJV92rpHK24xcJrzk20+tkeYlCPqcZNO3Lpni1OJWatPCcmgGDEqx7Om6lfa\nppM4k4BTe9+bsn3L9/9/yWhA0PwQGW8ipCZsnZt9lsdrYEM8z/M8z/M8z/M8z/M8z/MzLWY1\nAAAACUlEQVQ871H6P6JI+TxS5Wn2AAAAAElFTkSuQmCC",
  "mediaType": "image/jp2"
}

type: object
required:
  - bbox
properties:
  bbox:
    type: array
    oneOf:
      - minItems: 4
        maxItems: 4
      - minItems: 6
        maxItems: 6
    items:
      type: number
  crs:
    $ref: "bbox-def-crs.yaml"

"complexObjectInput": {
  "title": "Complex Object Input Example",
  "description": "This is an example of a complex object input.",
  "schema": {
    "type": "object",
    "required": [
      "property1",
      "property5"
    ],
    "properties": {
      "property1": {
        "type": "string"
      },
      "property2": {
        "type": "string",
        "format": "uri"
      },
      "property3": {
        "type": "number"
      },
      "property4": {
        "type": "string",
        "format": "date-time"
      },
      "property5": {
        "type": "boolean"
      }
    }
  }
}

"inputs": [
  .
  .
  .
  "complexObjectInput": {
    "value": {
      "property1": "value1",
      "property2": "value2",
      "property3": "value5"
    }
  },
  .
  .
  .
]

{
  "property1": "value1",
  "property2": "value2",
  "property3": "value5"
}

{
  "inputs": {
    "stringInput": "Value2",
    "measureInput": {
      "value": {
        "measurement": 10.3,
        "uom": "m",
        "reference": "https://ucum.org/ucum-essence.xml"
      }
    },
    "dateInput": "2021-03-06T07:21:00",
    "doubleInput": 3.14159,
    "arrayInput": [1,2,3,4,5,6],
    "complexObjectInput": {
      "value": {
        "property1": "value1",
        "property2": "value2",
        "property5": true
      }
    },
    "geometryInput": [
      {
        "value": "<gml:Polygon gml:id=\"GID1\" srsName=\"urn:ogc:def:crs:OGC::CRS84\"><gml:exterior><gml:LinearRing><gml:posList>-77.024519 38.810529 -77.024635 38.810973 -77.024704 38.810962 -77.024776 38.811239 -77.024957 38.81121 -77.024905 38.811012 -77.024905 38.811012 -77.024865 38.810857 -77.025024 38.810832 -77.025071 38.811012 -77.025203 38.810992 -77.02506 38.810444 -77.024519 38.810529</gml:posList></gml:LinearRing></gml:exterior></gml:Polygon>",
        "mediaType": "application/gml+xml; version=3.2"
      },
      {
        "value": {
          "type": "Polygon",
          "coordinates": [[[ -176.5814819, -44.10896301 ],
                           [ -176.5818024, -44.10964584 ],
                           [ -176.5844116, -44.11236572 ],
                           [ -176.5935974, -44.11021805 ],
                           [ -176.5973511, -44.10743332 ],
                           [ -176.5950928, -44.10562134 ],
                           [ -176.5858459, -44.1043396  ],
                           [ -176.5811157, -44.10667801 ],
                           [ -176.5814819, -44.10896301 ]]]
        }
      }
    ],
    "boundingBoxInput": {
      "bbox": [ 51.9, 7, 52, 7.1 ],
      "crs": "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
    },
    "imagesInput": [
      {
        "href": "https://www.someserver.com/ogcapi/Daraa/collections/Daraa_DTED/styles/Topographic/coverage?...",
        "type": "image/tiff; application=geotiff"
      },
      {
         "value": "VBORw0KGgoAAAANSUhEUgAABvwAAAa4CAYAAABMB35kAAABhGlDQ1BJQ0MgcHJvZmlsZQAA\nKJF9kT1Iw0AcxV9TpSL1A+xQxCFDdbIgKuKoVShChVArtOpgcumH0KQhSXFxFFwLDn4sVh1c\nnHV1cBUEwQ8QNzcnRRcp8X9JoUWMB8f9eHfvcfcOEOplplkdY4Cm22Y6mRCzuRUx9IogouhH\n ... \nj3Z5mX7/PCPVRJV92rpHK24xcJrzk20+tkeYlCPqcZNO3Lpni1OJWatPCcmgGDEqx7Om6lfa\nppM4k4BTe9+bsn3L9/9/yWhA0PwQGW8ipCZsnZt9lsdrYEM8z/M8z/M8z/M8z/M8z/MzLWY1\nAAAACUlEQVQ871H6P6JI+TxS5Wn2AAAAAElFTkSuQmCC",
         "encoding": "base64",
         "mediaType": "image/jp2"
      }
    ],
    "featureCollectionInput": {
      "value": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><FeatureCollection xmlns=\"http://schemas.myserver.com/namespaces/null\" xmlns:gml=\"http://www.opengis.net/gml/3.2\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xsi:schemaLocation=\"http://schemas.myserver.com/namespaces/null https://www.pvretano.com/myserver/ogcapi/daraa/schema?f=GML32&amp;collectionids=TransportationGroundCrv http://www.opengis.net/gml/3.2 http://schemas.opengis.net/schemas/gml/3.2.1/gml.xsd\">...",
      "mediaType": "application/gml+xml; version=3.2"
    }
  },
  "outputs": {
    "stringOutput": { },
    "measureOutput": { },
    "dateOutput": { },
    "doubleOutput": { },
    "arrayOutput": { },
    "complexObjectOutput": { },
    "geometryOutput": { },
    "boundingBoxOutput": { },
    "imageOutput": {
      "format": { "mediaType": "image/tiff; application=geotiff" }
    },
    "featureCollectionOutput": { }
  }
}

additionalProperties:
  $ref: "inlineOrRefData.yaml"

Client                                                                Server
  |                                                                     |
  |   POST /processes/compute-spectral-index/execution   HTTP/1.1       |
  |   Content-Type: application/json                                    |
  |   Link: <https://www.opengis.net/dev/profile/OGC/0/ogc-execute-reque|
  |          st>; rel="profile"                                         |
  |                                                                     |
  |   {                                                                 |
  |     "inputs": {                                                     |
  |       "spectral-index": "ndvi",                                     |
  |       "input-image": {                                              |
  |         "href": ".../sentinel-s1-l1c/S1A_EW_GRDM_1SDH_20240201T00375|
  |                  4_20240201T003859_052358_0654C4_86EE/measurement/ew|
  |                  -hh.tiff",                                         |
  |         "type": "image/tiff; application=geotiff"                   |
  |       }                                                             |
  |     },                                                              |
  |     "outputs": {                                                    |
  |       "spectral-index-output": {                                    |
  |       }                                                             |
  |     }                                                               |
  |   }                                                                 |
  |-------------------------------------------------------------------->|
  |                                                                     |
  |   HTTP/1.1 303 See Other                                            |
  |   Location: https://www.example.com/resp/job-01/spectral-index.tiff |
  |   Content-Type: image/tiff; application=geotiff                     |
  |   Content-Length: 13101963                                          |
  |<--------------------------------------------------------------------|

7.13.  Retrieve status information about a job

The following section describes the requirements to retrieve information about the status of a job.

allOf:
  - $ref: "./descriptionType.yaml"
  - type: object
    required:
      - id
      - status
      - type
    properties:
      id:
        type: string
      processID:
        type: string
        format: uri
      type:
        type: string
        example:
          - process
          - wps
          - openeo
      request:
        oneOf:
          - type: string
          - type: object
          - $ref: "../common-core/link.yaml"
      status:
        $ref: "statusCode.yaml"
      message:
        type: string
      exception:
        $ref: "../common-core/exception.yaml"
      created:
        type: string
        format: date-time
      started:
        type: string
        format: date-time
      finished:
        type: string
        format: date-time
      updated:
        type: string
        format: date-time
      progress:
        type: integer
        minimum: 0
        maximum: 100
      links:
        type: array
        items:
          $ref: "../common-core/link.yaml"

type: string
nullable: false
enum:
  - accepted
  - running
  - successful
  - failed
  - dismissed

GET /jobs/81574318-1eb1-4d7c-af61-4b3fbcf33c4f HTTP/1.1
Host: processing.example.org

{
  "jobID" : "81574318-1eb1-4d7c-af61-4b3fbcf33c4f",
  "status": "accepted",
  "message": "Process started",
  "progress": 0,
  "created": "2021-05-04T10:13:00+05:00",
  "links": [
    {
      "href": "http://processing.example.org/oapi-p/jobs/81574318-1eb1-4d7c-af61-4b3fbcf33c4f",
      "rel": "self",
      "type": "application/json",
      "title": "this document"
    }
  ]
}

7.14.  Retrieve job results

name: outputs
in: query
required: false
schema:
  type: array
  items:
    type:string
style: form
explode: false

GET /jobs/81574318-1eb1-4d7c-af61-4b3fbcf33c4f/results HTTP/1.1
Host: processing.example.org

{
  "stringOutput": "Value2",
  "measureOutput": {
    "value": {
      "measurement": "10.3",
      "uom": "m",
      "reference": "https://ucum.org/ucum-essence.xml"
    }
  },
  "dateOutput": "2021-03-06T07:21:00",
  "doubleOutput": "3.14159",
  "arrayOutput": [1,2,3,4,5,6],
  "complexObjectOutput": {
    "value": {
      "property1": "value1",
      "property2": "value2",
      "property5": true
    }
  },
  "geometryOutput": [
    {
      "value": "<gml:Polygon gml:id=\"GID1\" srsName=\"urn:ogc:def:crs:OGC::CRS84\"><gml:exterior><gml:LinearRing><gml:posList>-77.024519 38.810529 -77.024635 38.810973 -77.024704 38.810962 -77.024776 38.811239 -77.024957 38.81121 -77.024905 38.811012 -77.024905 38.811012 -77.024865 38.810857 -77.025024 38.810832 -77.025071 38.811012 -77.025203 38.810992 -77.02506 38.810444 -77.024519 38.810529</gml:posList></gml:LinearRing></gml:exterior></gml:Polygon>",
      "mediaType": "application/gml+xml; version=3.2"
    },
    {
      "value": {
        "type": "Polygon",
        "coordinates": [[[ -176.5814819,-44.10896301 ],
                         [ -176.5818024,-44.10964584 ],
                         [ -176.5844116,-44.11236572 ],
                         [ -176.5935974,-44.11021805 ],
                         [ -176.5973511,-44.10743332 ],
                         [ -176.5950928,-44.10562134 ],
                         [ -176.5858459,-44.1043396  ],
                         [ -176.5811157,-44.10667801 ],
                         [ -176.5814819,-44.10896301 ]]]
      }
    }
  ],
  "boundingBoxOutput": {
    "bbox": [51.9,7,52,7.1],
    "crs": "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
  },
  "imagesOutput": [
    {
      "href": "https://www.someserver.com/ogcapi/Daraa/collections/Daraa_DTED/styles/Topographic/coverage?...",
      "type": "image/tiff; application=geotiff"
    },
    {
      "value": "VBORw0KGgoAAAANSUhEUgAABvwAAAa4CAYAAABMB35kAAABhGlDQ1BJQ0MgcHJvZmlsZQAA\nKJF9kT1Iw0AcxV9TpSL1A+xQxCFDdbIgKuKoVShChVArtOpgcumH0KQhSXFxFFwLDn4sVh1c\nnHV1cBUEwQ8QNzcnRRcp8X9JoUWMB8f9eHfvcfcOEOplplkdY4Cm22Y6mRCzuRUx9IogouhH\n ... \nj3Z5mX7/PCPVRJV92rpHK24xcJrzk20+tkeYlCPqcZNO3Lpni1OJWatPCcmgGDEqx7Om6lfa\nppM4k4BTe9+bsn3L9/9/yWhA0PwQGW8ipCZsnZt9lsdrYEM8z/M8z/M8z/M8z/M8z/MzLWY1\nAAAACUlEQVQ871H6P6JI+TxS5Wn2AAAAAElFTkSuQmCC",
      "encoding": "base64",
      "mediaType": "image/tiff; application=geotiff"
    }
  ],
  "featureCollectionOutput": {
    "value": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><FeatureCollection xmlns=\"http://schemas.myserver.com/namespaces/null\" xmlns:gml=\"http://www.opengis.net/gml/3.2\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xsi:schemaLocation=\"http://schemas.myserver.com/namespaces/null https://www.pvretano.com/myserver/ogcapi/daraa/schema?f=GML32&amp;collectionids=TransportationGroundCrv http://www.opengis.net/gml/3.2 http://schemas.opengis.net/schemas/gml/3.2.1/gml.xsd\">...",
    "mediaType": "application/gml+xml; version=3.2"
  }
} 

8.1.  REQUIREMENTS CLASS “COLLECTION INPUT”