In January, the Open Geospatial Consortium (OGC) released Part 1 of the OGC API – Processes standard. As one of the editors, I would like to provide a short introduction to the API.
The OGC API – Processes (OAPIProc) builds upon the OGC Web Processing Service (WPS) 2.0 standard and can be used to transform geospatial data into geospatial information using current Web standards.
The OGC API family defines API building blocks to spatially enable Web-APIs for data download and processing. The OAPIProc is the third approved API in the OGC API family.
The OAPIProc defines the following end points:
The OAPIProc can be described using OpenAPI 3.0. You can find an example here.
Initially, the OAPIProc was closely aligned to the WPS standard to ease the implementation of the API on top of existing WPS frameworks. This still holds for the operations that WPS is offering, which can be mapped to the respective API end points.
A major difference is the definition of input/output data types. The WPS standard defines three data types for input/output data:
- Literal data, for simple number or text values
- Complex data, for raster or vector data in different formats
- Boundingbox data, legacy data type for defining bounding boxes
The OAPIProc has moved away from these three fixed data types and leaves the definition of input/output data open. The data types are defined using JSON schema. The following examples should give an impression of the capabilities of this approach.
This snippet shows the definition of a simple string input:
This snippet shows the definition of a complex vector input that can have different formats:
The body of the request that triggers an execution (POST to end-point: /processes/{process-id}/execution) was also completely overhauled. Apart from the benefit of using JSON over XML, the elements of the request body have been reduced to a minimum.
Below you can see a WPS execute XML request with two inputs that are returned as outputs:
Now a similar request body as defined by OAPIProc:
The OAPIProc integrates seamlessly into the family of OGC APIs. The goal was to make it as convenient as possible for developers of Web-APIs to adopt the standard. The new description format gives a high degree of freedom to define inputs and outputs as needed.
There are already implementations of OAPIProc servers and clients available. You can find them here.
At the moment, the OGC working group is working on two additional parts of the OAPIProc:
- OGC API – Processes – Part 2: Deploy, Replace, Undeploy
- OGC API – Processes – Part 3: Workflows and Chaining
52°North is currently working in several projects on a software framework for publishing lightweight OAPIProc services in different environments (e.g., local processing systems or cloud infrastructures). We hope that we have raised your interest in the OGC API – Processes and would love to hear your thoughts!
