3.1.1.1.  Terminology

The different entities specified in STAC and OAR1 can be mapped as follows.

Table 1

Nevertheless, there may be other mappings between concepts and properties in the specifications. Some may argue a STAC Collection is a OAR1 Record. Due to the way the JSON representations are defined, a mapping as in the table above is assumed.

Please also note that Catalogs, Collections, and Items could be Records in OAR1 and some implementations only convert Records to Record Collections once there is at least one child record. Catalogs are currently mostly used in static deployments and do not play a huge role in APIs/dynamic deployments.

3.1.2.1.  Catalogs

Assuming a JSON (non-GeoJSON) encoding.

Table 2

See below for more details about Collections.

3.1.2.2.  Collections

Assuming a JSON (non-GeoJSON) encoding.

Table 3

3.1.2.3.  Items / Records

The following assumes a GeoJSON encoding for Records.

3.1.5.1.  Landing Page

As both the STAC and OAR1 landing pages are consistent with the requirements specified in the OGC API — Common Standard, the landing pages are very similar.

In OAR1 an implementation must provide just links and can optionally add title and description.

An implementation of the STAC API requires additional properties (stac_version, type, id, description) to form a full STAC Catalog. The STAC API implementation also lists the conformance test classes in the landing page, while OAR1 has the implementation separate.

The use of links is a bit different in STAC API and OAR1 implementations. The implementation of the Collection List is optional in STAC. A STAC API implementation can also just expose child links to catalogs/collections and/or to a search endpoint.

3.1.5.2.  Conformance

Both endpoints are 100% equivalent. OAR1 requires a separate endpoint that lists conformance test classes, which is optional in STAC API. A STAC API implementation additionally lists the conformance classes in the landing page.

3.1.5.3.  Collection List

As the endpoints for collection lists are both based of OGC API — Features — Part 1, the endpoints are very similar. The difference between STAC and OAR1 is how the individual collections are encoded, see Collections for details.

3.1.5.4.  Individual Collection

As the endpoints for individual collections are both based of OGC API — Features — Part 1, the endpoints are very similar. The difference between STAC and OAR1 is how the individual collections are encoded, see Collections for details.

3.1.5.5.  Item List

As the endpoints for item lists (per collection) are both based of OGC API — Features — Part 1, the endpoints are very similar. The difference between STAC and OAR1 is how the individual items are encoded, see Items for details. Additionally, OAR1 defines the following parameters that implementations must support: q, type, and externalid.

3.1.5.6.  Individual Item

As the endpoints for individual items are both based on top of OGC API — Features — Part 1, the endpoints are very similar. The difference between STAC and OAR1 is how the individual items are encoded, see Items for details.

3.1.5.7.  Search

STAC defines three ways to search for resources:

OAR1 defines similar ways to search for resources:

3.1.5.8.  Datacubes

OAR1 does not prescribe how to provide metadata about datacubes. OGC in general has a couple of related standards, e.g., OGC API Coverages and the draft GeoDataCube API, but the relation with OAR1 is not clearly defined for any of them.

STAC does not provide metadata about datacubes either in the core, but it has a datacube extension.

3.2.3.1.  Well-known document

openEO clients usually first connect to the well-known document to discover different versions or implementations of a server. Thus a client can choose a suitable API version including choosing between production and development instances. Then the openEO client connects to the selected instance’s landing page. OGC API — Processes clients always directly connect to a landing page. openEO clients can also directly connect to the landing page.

This folder structure with the document typically resides outside of the actual API implementations, i.e., in the root of the host or domain.

3.2.3.2.  Landing page

As the landing pages are both consistent with OGC API — Common, the landing pages are very similar.

Some differences include the following.

3.2.3.3.  Conformance classes

Both conformance test class endpoints are 100% equivalent. OAP1 requires a separate endpoint that lists conformance test classes. openEO additionally supports listing the conformance test classes in the landing page (follows STAC API). Conformance test classes are only fully defined since openEO API v1.2.0.

3.2.6.1.  Pre-defined processes

In openEO GET /processes operation returns the full process metadata, while an OAP1 implementation only returns a summary. The general structure of the response of GET /processes is the same (processes and links). The OGC Process Description and the openEO process description are not compatible.

openEO does not yet define an endpoint to retrieve an individual process such as a OAP1 GET /processes/{processID} endpoint will. There is a proposal available to add such an endpoint to the openEO specification. openEO has the concept of namespace for processes though and thus defines the endpoint at
GET /processes/{namespace}/{process} which would conflict with the OAP1 definition.

Some notable differences in the process description (only fully delivered via GET /processes/{processID}) include the following.

Below is a simple process encoded in the two variants discussed here.

3.2.6.2.  User-defined processes / Workflows

Workflows are not described in the OGC API — Processes — Part 1 Standard. Instead, the draft Part 2 extension defines the deployment/management of workflows and the Part 3 extension specifies how to define the workflows. The Part 2 extension defines how to chain/nest processes in an OGC API — Processes implementation and also defines a “workflow language” (“Modular OGC API Workflow JSON”, short: MOAW), but it seems to also allow providing other workflow languages such as openEO user-defined processes and the Common Workflow Language (CWL).

openEO defines the /process_graphs endpoints and has workflows (called “user-defined processes” in openEO, i.e., a process with a process graph) included in the core.

Related documents:

A comparison between MOAW and openEO user-defined processes should also be considered in the future.

3.2.7.1.  Synchronous processing

3.2.7.2.  Batch Job processing

3.2.7.3.  On-demand processing

On-demand processing in this context means that processing is only executed for extents shown to the user, e.g., on a web map. Results are processed “on demand” depending on the interaction with the map (e.g., how Google Earth Engine does it in their Code Editor by default).

TBD, lower priority as it’s not covered by OAP1. It’s also optional and very different in openEO. Instead it is defined as a separate OAP1 API implementation for individual OGC API resources. For example, a combination of OGC API — Maps and OGC API — Processes.

3.3.2.1.  OGC

collection:

A set of features from a dataset.

coverage:

A feature that acts as a function to return values from its range for any direct position within its spatial, temporal, or spatio-temporal domain; this can be equivalent to either a STAC Item or Collection.

domain:

A set of direct positions along some axis in space and time (or other dimensions) that defines the “location” of a coverage, associated with a (compounding of) spatio(-temporal)(-other) coordinates reference system (CRS), and for each of which a set of 1+ values (range) are associated.

feature:

An abstraction of real world phenomena.

range:

A set of feature attribute values associated by a function with the elements of the domain of a coverage, that means the stored values of a coverage like for instance the spectral bands; in the STAC datacube extension, range and domain are condensed into the same cube:dimensions container.

3.3.2.2.  STAC

catalog:

A logical group of other catalog, collection, and item objects.

collection:

A set of common fields to describe a group of items that share properties and metadata

item:

A GeoJSON Feature augmented with foreign members relevant to a STAC object.

cube:dimensions:

A set of dimensions that can be of different types: spatial, temporal, “other,” etc.

3.3.3.1.  Meta / API capabilities

In this section the available information on the API capabilities is provided. This information is relevant for interoperability and “machine-actionable” services.

3.3.3.2.  Well-known URIs

Site-wide metadata information: In an openEO API implementation this is a list of versions of the API that the server supports, and it is meant to help a client choose the most suitable endpoint (eg. production/development).

Site-wide metadata is not specified in the draft OAC1 Standard.

3.3.3.3.  Landing page

The landing pages as defined in both specifications are consistent with the OGC API — Common Standard, and there are only minor differences in the returned schemas.

3.3.3.4.  Conformance

Both endpoints are 100% equivalent (openEO additionally supports the ability to list the conformance test classes in the landing page, following the STAC API).

3.3.3.5.  API description

Both openEO and OAC1 implementations can provide service descriptions (e.g., OpenAPI documents) and human-readable documentation in the resources pointed to by the standard service-desc and service-doc relation types. In an OAC1 implementation such resources (both) point to the /api endpoint.

3.3.3.6.  Authentication

The openEO specification defines two authentication mechanisms:
OpenID Connect (primary) and HTTP Basic (for development/testing). The draft OAC1 Standard does not define any authentication mechanisms. While both mechanisms could be implemented, OAC1 clients will likely not support them.

The availability of the authentication mechanisms is detected through the endpoints in the openEO landing page, while in OAC1 parse the OpenAPI document needs to be parsed for the authentication information (which implicitly requires a link to an OpenAPI 3.0 file with relation type service-desc in the landing page).

3.3.3.7.  Data discovery

openEO and OAC1 implementations both provide a resource for accessing the whole catalog of datacubes/coverages offered by the server. This includes basic/abbreviated metadata for each of the assets in order to try to keep the response size small. Full metadata details are instead available as per data description.

CIS coverages will be returned by an OAC1 request, STAC Collections by an openEO request.

Optionally, openEO specifies how to search for individual STAC items “hidden” inside the collections, as per STAC API repository.

3.3.3.8.  Data description

Full metadata descriptions of collections are available in both the openEO and OAC1 specifications, encoded as STAC Collections or CIS Coverages, respectively.

Additional links are provided (required) for coverages in an OAC1 implementation with respect to the basic “Collection Resources” as defined in the OGC API — Common Standard: One for the description of the sole “range” of the coverage, and one for the sole “domain,” which is just a subset of the full metadata description. Also available, though optional, is the link to the sole coverage’s “metadata,” meaning supplementary/domain-specific extra metadata fields that might be attached to a coverage.

The openEO specification offers a more flexible and machine-actionable solution for filtering the description of a collection. This is by means of the “queryables”: a listing of all metadata filters available for each collection. This is in line with both filter STAC API extension and the draft OGC API — Features — Part 3: Filtering Standard.

3.3.3.9.  Data access

OAC1 : Encoding as negotiated in the HTTP protocol, with a proper fallback media type otherwise. The actual coverage values (the range set) can be represented either in-line or by reference to an external file which may have any suitable encoding.

An openEO implementation provides access to the actual data by means of the load_collection process, which can be submitted either synchronously or asynchronously as a batch job. The format of the resulting data shall always be specified by chaining a save_result process.

For pre-filtering/data subsetting options, see next section.

3.3.3.10.  Data subsetting

The parameters offered by the openEO load_collection process supports subsetting the requested collection along a cube’s dimensions, which also includes what the OAC1 Standard calls the range set, hence the “bands” of the dataset. There is no option for low:high subsetting of an arbitrary dimension which might neither be classified as spatial nor temporal, like the subset query parameter offers in OAC1.

Spatial subsetting as defined in the openEO specification is more powerful as not only bounding-boxes but also GeoJSON geometries can be specified for a more accurate clipping of the data. On the other hand, OAC1 supports specifying open/unbounded spatial intervals. Open/unbounded time intervals are supported in both API specifications (via null or double-dots .., respectively).

Spatial filtering with coordinates specified with an arbitrary CRS is available in both API specifications. In both cases, all data values that spatially intersect with the provided spatial extent/range (boundaries included) will be in the response.

Subsetting of an arbitrary dimension — not classified as spatial not temporal, nor band in the openEO datacube model — is not possible in an openEO implementation, while available in an OAC1 implementation via subset parameters.

In case the response is too large, the current proposal is for an OAC1 implementation to return a URI instead of the content, or a reduced-resolution coverage with a URI to the full resolution response.

Filtering/cherry-picking of bands is available in both the OAC1 and openEO implementations via the properties parameter and load_collection process, respectively. Both band names and band indices can be used in an OAC1 implementation, while an openEO implementation only accepts band names.

An openEO compliant server can optionally provide a rough estimate of the time/cost of a stored job via /jobs/{jobId}/estimate. Server logs are also available from an openEO server implementation either directly in the synchronous processing response (as a link), or via the API resources dedicated to the batch jobs (eg. jobs/{jobId}/logs).

3.3.3.11.  Data scaling

Specifying how to rescaling a dataset in an openEO implementation requires the same procedure as for any other kind of processing, thus preparing a process graph that executes the desired operation, then fetch the results, either synchronously or asynchronously through the creation of a batch job.

At of February 2024, the available openEO specified processes for data resampling are resample_spatial — that rescales the spatial dimensions to a target resolution, or to a target spatial coordinate reference system — and resample_cube_spatial/ resample_cube_temporal, that rescale the spatial/temporal dimensions to match the resolutions of a provided target datacube.

While an OAC1 implementation does not let a user specify a resolution, a client can specify the target number of samples along a dimension, or the scaling factor. While the capabilities of a user-defined process with asynchronous job management go well beyond data, the resampling of a dataset provides a wide range of benefits, the OAC1 Standard provides a somewhat simpler shortcut for via query parameters of the URL.

The OAC1 Standard also supports specifying scaling on any coverage’s dimension, while openEO only supports scaling along the spatial plane/dimensions.

3.3.3.12.  Tiles

The OAC1 Standard, in alignment with the requirements defined in the OGC API — Tiles Standard, supports the retrieval of coverage data in form of tiles. The tiled content is trimmed and resampled to match the boundaries and resolution of a given tile. More than one tileset can be attached to a coverage.

The openEO specification does not specify how to provide tiled access directly, but can be easily cascaded by a dedicated secondary tiles service (like XYZ tiles) thanks to the /service_types resource.

3.3.3.13.  Media encoding

Both the OAC1 and openEO specifications provide a list of data formats the server supports, both the data formats that the server can read from (input) and write to (output).

OAC1 embeds the information in the API description available at the /api endpoint and does not mandate any particular output encoding or format, although CIS JSON is recommended. Binary formats of course are also allowed (CIS RDF, NetCDF, GeoTIFF, PNG, JPEG, JPEG-2000, etc.).

In the openEO specification format names and parameters are aligned with the GDAL/OGR formats although custom file formats are also permitted.

5.1.1.1.  Introduction

xcube is an open source data cube framework under development by Brockmann Consult GmbH (BC) since 2018. xcube is based on the Python scientific software stack, in particular the xarray package and Zarr storage format. The server component of xcube provides a modular plug-in framework for the implementation of datacube-related web services. Server plug-ins for a number of standard and in-house APIs have already been released, and the Testbed-19 Geodatacube is being implemented as an additional server plug-in.

5.1.1.2.  Development and deployment process

Like all xcube code, the GeoDataCube server plug-in is being developed openly at https://github.com/dcs4cop/xcube and released under the open-source MIT license. The GeoDataCube features are being added in a series of short-lived branches which are merged with the master branch at regular intervals; releases (usually several per year) are made directly from the master branch as Git tags, GitHub releases, Docker images, and conda-forge packages. The GeoDataCube implementation is thus being automatically integrated into the mainline xcube releases.

5.1.1.3.  Public server instance

Our API backend server is at https://testbed19.api.dev.brockmann-consult.de/api/ogc. The deployment is updated regularly with the latest codebase from the Testbed-19 development branch, if one currently exists, or the master branch if not.

5.1.1.4.  Deploying an xcube server

Since xcube is open source, a server instance can be installed and initialized by any Testbed 19 participant or other interested party. See the xcube documentation at https://xcube.readthedocs.io/ for details on how to install, configure, and run the xcube server. Note that the latest Testbed-19 developments may only be available in a development branch.

The datasets and configuration used in the deployment are also public. To start an xcube server with the same configuration as the BC deployment, run

xcube serve --port 8000 --config s3://xcube-viewer-app/testbed19/dev/api/server-config.yaml

5.1.1.5.  Available datasets

BC has ingested the datasets listed below, as specified in Use Case B of the OGC Call for Proposals. Ingested data cover at minimum the area of interest defined by the use case.

Table 7

Some additional datasets, unrelated to the use case, are also published by the server. The datasets are not listed in the table but can be explored via the Brockmanns GDC instance.

5.1.2.1.  Supported Capabilities

The supported OGC API Coverages capabilities include the Core, Subsetting, Scaling, Field Selection, as well as Coverage Tiles. The supported OGC API Processes capabilities include the Core and OGC Process Description. The Ecere implementation also supports additional OGC standards that integrate with the GDC API. They are all listed as follows.

5.1.2.2.  Data cubes (collections) of interest

Several data cubes were made available from the GDC API deployment, covering the range of use cases identified for the project:

Climate and weather datasets

Static environmental data

Categorical coverage (similar use case to land use / land cover maps)

Remote sensing image time series

For all of the above datasets, /coverage will return the raw data values, while /map will return an addressable RGB (ARGB) map in some default style (/styles/{styleId}/map may return maps in different styles).

Administrative and environmental spatial units (vector maps)

These datasets are accessible from the GDC API deployment as OGC API — Features, OGC API — Tiles (tiled vector feature data and tiled maps), as well as OGC API — Maps.

Statistics

5.1.2.3.  Processes of interest

NOTE: The output of this process is not a coverage in the true sense in that the fields are ARGB values intended to be displayed directly rather than raw values.

5.1.2.4.  Addressing Use Case Requirements

Table 8 — Use case A (mapping of capabilities)

Table 9 — Use case B (mapping of capabilities)

Table 10 — Use case C (mapping of capabilities)

5.1.2.5.  Example use of implementation

In this example, use of the Filtering and Derived field extensions, a GeoTIFF coverage is returned from the GNOSIS GDC API implementation for the average Near Surface Air Temperature, converts the temperature from Kelvin to Celsius, and filters out cells where the difference between maximum and minimum is not greater than 10 degrees.

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/coverage?
   filter=(tasmax-tasmin) > 10&
   properties=tas-273.15&
   f=geotiff

Listing 3 — OGC API - Coverages request from GNOSIS Map Server using CQL2 expressions to filter cells by values and convert Kelvin to Celsius

Figure 2 — Coverage output of above request, with a color map style applied in QGIS

In this other example, a coverage is returned from the sentinel-2 filtering out cloudy data using the Scene Classification Layer field and computing an Enhanced Vegetation Index from the Near-Infrared, red, and blue bands.

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage?
   properties=2.5 * (B08 / 10000 - B04 / 10000) / (1 + B08 / 10000 + 6 * B04 / 10000 + -7.5 * B02 / 10000)&
   filter=(SCL >=4 and SCL <= 7) or SCL=11&
   subset=Lat(38.9:39.1),Lon(-4.8:-4.6),time("2017-09-04T11:18:26Z")&
   crs=[EPSG:4326]&
   scale-size=2000,2000&
   f=geotiff

Listing 4 — OGC API - Coverages request from GNOSIS Map Server using CQL2 expressions to compute an Enhanced Vegetation Index (EVI) and filter out clouds

Figure 3 — Coverage output of above request, with a color map styled applied in QGIS

The following is an example using Processes — Part 3 — ”Collection input” / “output” execution calculating an NDVI from sentinel-2 Level-2A data cube that can be POSTed to

https://maps.gnosis.earth/ogcapi/processes/PassThrough/execution?response=collection:

{
   "process" : "https://maps.gnosis.earth/ogcapi/processes/PassThrough",
   "inputs" : {
      "data" : [
         {
            "collection" : "https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a",
            "properties" : [ "(B08 - B04) / (B08 + B04)" ]
         }
      ]
   }
}

Listing 5 — Example PassThrough process execution request (for Collection Output)

From the resulting virtual collection one can then request a coverage subset for a particular area, time and resolution of interest:

https://maps.gnosis.earth/ogcapi/collections/temp-exec-5CB51B82/coverage?subset=Lat(-16.259765625:-16.2158203125),Lon(124.4091796875:124.453125),time("2022-06-28")

or a map:

https://maps.gnosis.earth/ogcapi/collections/temp-exec-5CB51B82/map?subset=Lat(-16.259765625:-16.2158203125),Lon(124.4091796875:124.453125),time("2022-06-28")

(or coverage tiles, or map tiles, or DGGS zone data…​) triggering on-the-fly processing.

With authentication, a POST of this execution request to /collections could also automatically create a new collection. The following is an equivalent example using Part 1 — Core synchronous execution (instead of collection input/output) that can be POSTed to

https://maps.gnosis.earth/ogcapi/processes/PassThrough/execution.

This example still uses a Part 3 input field modifiers, the "properties" which is at the same level as the "href."

{
   "inputs" : {
      "data" : [
         {
            "href" : "https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage?subset=Lat(-16.259765625:-16.2158203125),Lon(124.4091796875:124.453125),time(\"2022-06-28\")&properties=B04,B08&f=image/tiff;application=geotiff",
            "properties" : [ "(band2 - band1) / (band2 + band1)" ]
         }
      ]
   }
}

Listing 6 — Example PassThrough process execution request (for Synchronous execution)

Unlike the Collection input/output approach, here the Area/Time/Resolution of interest is implied from those of the “data” input avoiding the need for separate inputs that would specify these, which would be meaningless in Collection Input/Output and would complicate the implementation of processes that support both approaches. Whereas the Collection approach is fully re-usable for any area/time/resolution of interest, this synchronous execution request is only usable once. Note that the names of the bands changed to the default ones that are understood from accessing the GeoTIFF, since GeoTIFF does not currently support encoding band names. With collection input, the fields can be known from the collection schema (to which the Coverages API is transitioning) or currently from the Coverage RangeType. It should also be possible to chain this execution request with the RenderMap process using the Part 3 — Nested process (or Remote Process for the case where the two processes are on different servers) in order to retrieve a rendered map instead of a coverage.

5.1.2.6.  Future work: geometry intersections, spatial joins, aggregation and convolution

The planned OGC API — Coverages — Part — 2: Filtering, deriving fields, aggregation and convolution extension would define common OGC API building blocks that support filters which values get returned and derived new values using CQL2 expressions.

A Part 2 requirements class could also enable joins with other collections, including feature collections, using a joinCollections parameter, facilitating the integration of vector and raster data. The fields from the joined collections would become available for use within the filter and derived field expressions.

An additional example use of the filtering extension would cover different types of queries supported by OGC API — EDR use cases, such as trajectories, by using the CQL2 S_INTERSECTS() spatial relation function together with a WKT geometry such as a LineString. Only the data cube cells matching the function would be returned.

filter=S_INTERSECTS(rec.cells, POLYGON((-109 64.39894807, -61.25 64.39894807,
      -61.25 76.7652818, -109 76.7652818, -109 64.39894807)))

Listing 7 — Filtering using CQL2 polygon geometry

This extension could also define standardized functions allowing the user to perform aggregation along one or more dimensions, using specific aggregating operations such as minimum or average.

properties= Aggregate(tasmax, 'max', ['time']),
               Aggregate(tasmin, 'min', ['time'])&
   subset=time("2020-01-01":"2020-01-10")

Listing 8 — Aggregating on temporal dimension using CQL2 expression

Another standardized function could allow performing convolution, where operations on cell kernels allow the user to easily implement advanced capabilities such as edge detections. This example prototypes defining a Sobel operator used in such use cases:

properties=
   (
      Convolve(B04, [1,0,-1,2,0,-2,1,0,-1], ['Lat','Lon']) ^ 2 +
      Convolve(B04, [1,2,1,0,0,0,-1,-2,-1], ['Lat','Lon']) ^ 2
   ) ^ 0.5&
   subset=Lat(38.9:39.1),Lon(-4.8:-4.6),
   time("2017-04-12T11:17:08Z":"2017-09-04T11:18:26Z")

Listing 9 — Sobel operator (kernel convolution) implemented as a CQL2 expression

These additional capabilities would likely address a large majority of processing use cases, which can also be achieved with WCPS, openEO, and OGC API — Processes execution requests involving multiple processes, using a more intuitive and concise syntax that can be readily combined with the other building blocks defined in OGC API — Coverages.

5.1.3.1.  Supported Capabilities

The implemented Coverages API capabilities includes the Core, Subsetting, and Field Selection (from OGC API — Coverages).

The following request parameters are thus available.

Further Notes:

5.1.3.2.  Data cubes (collections) of interest

A single data cube was made available from the GDC API deployment. However, the openEO collections available on Eurac Research’s back-end could also easily be enabled to be available via the GDC API implementation.

The /coverage request will return the raw data values.

5.1.3.3.  Example use of implementation

A sample GET/coverage request to the Eurac Research server instance is the following:

https://dev.openeo.eurac.edu/collections/s2_l2a/coverage?properties=blue,green,red&datetime=2022-07-01T00:00:00Z/2022-07-05T00:00:00Z&bbox=11.26,46.45,11.40,46.52&f=geotiff

The request specifies an area of interest above the city of Bolzano, where Eurac Research is located. The request selects only the blue, green, and red bands using the properties filtering and stores the result as a GeoTIFF.

Figure 4 — OGC API - Coverages request from Eurac Research client (GDC Web Editor) to our server, visualized as an RGB composite

5.1.3.4.  Future work: GDC API alignment, OGC Processes implementation

Eurac planned to work on the EUMETSAT Use Case, but unfortunately developing the current functionality took longer than expected. Additionally, no implementation for OGC API Processes has been released in Eurac’s server yet. Therefore, a possible future work could consist of implementing the OGC API Processes Part:1 standard and trying to harmonize and integrate it with the currently available openEO processes and related workflows encoded in the openEO process graph. This could also be further expanded into a first implementation of OGC API processes part:3.

5.1.4.1.  ZOO-Project with Deploy, Replace, Undeploy (DRU) support to deploy OpenEO User Defined Processes

The service documentation contains examples for deploying and executing a simple User Defined Process OpenEO graph.

{
  "processDescription": {
    "id": "fahrenheit_to_celsius",
    "title": "Convertion from fahrenheit to celsius",
    "abstract": "Convertion from fahrenheit to celsius",
    "version": "0.0.1",
    "inputs": {
      "f": {
        "title": "Degrees Fahrenheit",
        "description": "Degrees Fahrenheit",
        "schema": {
          "type": "number",
          "default": 10,
          "format": "double"
        }
      }
    },
    "outputs": {
      "result": {
        "title": "Degrees Celsius",
        "description": "Degrees Celsius",
        "schema": {
          "type": "number",
          "format": "double"
        }
      }
    }
  },
  "executionUnit": {
    "format": {
      "mediaType": "application/openeo",
    }
    "value": {
      "process_graph": {
        "subtract1": {
          "process_id": "subtract",
          "arguments": {
            "x": {
              "from_parameter": "f"
            },
            "y": 32
          }
        },
        "divide1": {
          "process_id": "divide",
          "arguments": {
            "x": {
              "from_node": "subtract1"
            },
            "y": 1.8
          },
          "result": true
        }
      }
    }
  }
}

5.1.4.2.  ZOO-Project with Data Discovery / Access provided by eoAPI and Account Management using Keycloack

5.1.5.1.  GDC-API implementation

In Testbed-19, the proposed GDC-API were partially implemented in rasdaman community. Specifically:

The rasdaman GDC-API implementation is available for access from clients at https://testbed19.rasdaman.com/rasdaman/gdc. Implementers of GDC-API clients were provided with access credentials for testing.

5.1.5.2.  Data for Use-Case Scenarios

To support the Use-Case scenarios, the Testbed participants imported various data and made the data available through the GDC-API endpoint. The https://testbed19.rasdaman.com website provides an overview of the available datacubes.

UC A

UC B

UC C

5.1.5.3.  Results

Mapping the GDC and OAPI-Covreages requests turned out to be straightforward. Only a subset of the query language capabilities was used. WCPS provides a solid basis for the variety of geo datacube APIs that have emerged in the meantime, such as WCS GET, WCS POST/XML, WCS SOAP, OAPI-Coverages, and now additionally the draft GDC API specification. A caveat is that the more recent API specifications convey subtle differences in use and semantics, which required a careful mapping. Here, WCPS can serve as the canonical expression which allows the user to capture and document such differences exactly.

5.1.6.1.  Supported standards or drafts

The following capabilities outlined in the proposed GDC API specification will be implemented:

The endpoint is http://oge.whu.edu.cn/geocube/gdc_api_t19.

5.1.6.2.  Available datasets for use-case scenarios

Partial datasets from use case B and use case C were collected. Separate cubes have been established for each data product, incorporating three fundamental dimensions: time, space, and band. Moreover, these cubes can accommodate additional dimensions based on the distinct characteristics of each product.

Use case B

Use case C

5.1.6.3.  STAC API implementation

Example: http://oge.whu.edu.cn/geocube/gdc_api_t19/collections

The response body contains key attributes as specified by STAC and also includes key attributes required by the OGC API — Common Standard.

Example: http://oge.whu.edu.cn/geocube/gdc_api_t19/collections/ECMWF_ht3e

The response body equally contains the key attributes required by both the OGC API — Common Standard and STAC respectively.

Example: http://oge.whu.edu.cn/geocube/gdc_api_t19/collections/ECMWF_ht3e/queryables

All dimensions in the specific cube, apart from the spatial dimension, will be returned as queryable items.

Example: http://oge.whu.edu.cn/geocube/gdc_api_t19/collections/ECMWF_ht3e/items?filter=pressure=1000

The response body includes metadata information for all scenes in the data cube. This endpoint supports dimension condition filtering via cql2: only cql-text encoding is supported.

Example: http://oge.whu.edu.cn/geocube/gdc_api_t19/collections/ECMWF_ht3e/items/ht3e_1000_129.128_0

The response body includes metadata information for a single scene and a link for data retrieval.

5.1.6.4.  OGC API — Coverages implementation

Example: http://oge.whu.edu.cn/geocube/gdc_api_t19/collections/ECMWF_ht3e/coverage?bbox=0,35,40,70&datetime=2016-10-28T01:01:00Z/2016-10-28T02:01:00Z&properties=Divergence&subset=pressure(1000)&f=tif

The endpoint supports retrieving data from the data cube and returning the data in either GeoTIFF or netCDF format. The endpoint also supports query parameters such as bbox, datetime, properties, subset, scale-size, scale-axes, scale-factor, and format (tif, netCDF) to return the data relevant to the area of interest.

Example: http://oge.whu.edu.cn/geocube/gdc_api_t19/collections/ECMWF_ht3e/coverage/domainset

The endpoint returns the domainset of the coverage, which includes all dimensions of the cube except for the band dimension.

Example: http://oge.whu.edu.cn/geocube/gdc_api_t19/collections/ECMWF_ht3e/coverage/rangetype

The endpoint returns the rangetype of the coverage, which includes information about the band (or variable) dimension.

5.1.6.5.  OGC API — Processes implementation

Example: http://oge.whu.edu.cn/geocube/gdc_api_t19/processes

This implementation offers a series of predefined processes, including data loading (loadCube), mathematical operations (add, subtract, divide, normalize), and aggregation operations (aggregate), among others.

Example: http://oge.whu.edu.cn/geocube/gdc_api_t19/processes/aggregate

Example: http://oge.whu.edu.cn/geocube/gdc_api_t19/processes/aggregate/execution

Request body example:

{
    "process": "http://oge.whu.edu.cn/geocube/gdc_api_t19/processes/aggregate",
    "inputs": {
        "data": {
            "process": "http://oge.whu.edu.cn/geocube/gdc_api_t19/processes/normalize",
            "inputs": {
                "data": {
                    "process": "http://oge.whu.edu.cn/geocube/gdc_api_t19/processes/loadCube",
                    "inputs": {
                        "cubeName": "SENTINEL-2 Level-2A MSI",
                        "extent": "4.7,51.7,4.85,51.8",
                        "startTime": "2019-01-17 00:00:00",
                        "endTime": "2019-01-20 00:00:00"
                    }
                },
                "dimensionName": "bands",
                "dimensionMembers": ["B8", "B3"]
            }
        },
        "dimensionName": "time",
        "method": "mean"
    }
}

Listing 11

The endpoint supports local processes nesting and exclusively operates in asynchronous execution mode, creating a job upon execution.

Example: http://oge.whu.edu.cn/geocube/gdc_api_t19/jobs

The endpoint returns all existing jobs.

Example: http://oge.whu.edu.cn/geocube/gdc_api_t19/jobs/34b59622-0faf-4fb2-8029-1fe824d7f51b

The endpoint returns the information about a specific job, including the execution status.

Example: http://oge.whu.edu.cn/geocube/gdc_api_t19/jobs/34b59622-0faf-4fb2-8029-1fe824d7f51b/results

The endpoint returns the execution result of the process.

Example: http://oge.whu.edu.cn/geocube/gdc_api_t19/processes/aggregate/execution?response=collection

Request body example:

{
    "process": "http://oge.whu.edu.cn/geocube/gdc_api_t19/processes/aggregate",
    "inputs": {
        "data": {
            "process": "http://oge.whu.edu.cn/geocube/gdc_api_t19/processes/normalize",
            "inputs": {
                "data": {
                    "process": "http://oge.whu.edu.cn/geocube/gdc_api_t19/processes/loadCube",
                    "inputs": {
                        "cubeName": "SENTINEL-2 Level-2A MSI"
                    }
                },
                "dimensionName": "bands",
                "dimensionMembers": ["B8", "B3"]
            }
        },
        "dimensionName": "time",
        "method": "mean"
    }
}

Listing 12

The response will redirect to a description document of a collection. This service supports triggering computations through the retrieval mechanism of OGC API — Coverages and provides the computation results.

Example: http://oge.whu.edu.cn/geocube/gdc_api_t19/collections/bf5aa1a0-a492-4345-9476-3d610cdc3b9f/coverage?subset=time(2019-01-17T00:00:00Z”:”2019-01-20T00:00:00Z”),Lon(4.7:4.85),Lat(51.7:51.8”/>)

5.2.1.1.  Supported capabilities

The following are the supported OGC API capabilities:

The capabilities based on openEO were not implemented for this client.

5.2.1.2.  Example use of implementation

The following image demonstrates visualizing CMIP5 data for wind velocity retrieved from the Copernicus Data Store. In addition to the spatial and temporal dimension, this datacube includes an atmospheric pressure dimension. The client supports changing the pressure level for selecting the slice of the atmosphere to visualize.

Figure 5 — Cartographer visualizing CMIP5 pressure and wind velocity

The following image shows a visualization of ERA5 relative humidity data which was also retrieved from the Copernicus Data Store. This dataset also includes at an atmospheric pressure dimension, with a finer granularity of pressure levels. The spatial and temporal resolution is also higher, whereas only a small subset for six days was loaded onto the server.

Figure 6 — Cartographer visualizing relative humidity

5.2.5.1.  Supported approved standards and drafts standards

5.2.5.2.  Implementation

OGC API — Coverages

The OGE-DataClient automatically generates corresponding filtering conditions by parsing the metadata information of the data cube, including rangetype and domainset. Users can retrieve subsets of data as needed.

Figure 7 — WHU’s OGE-DataClient visualizing climate:era5:relativeHumidity from Ecere Coverages API

OGC API — Processes

The OGE-DataClient allows users to create execution requests in a JSON editor, including the request body for individual process execution and nested workflows. Supported execution modes include synchronous, asynchronous, and collection output. In collection output mode, users can easily reuse the same workflow by applying different conditional retrievals to the returned Coverage.

Figure 8 — WHU’s OGE-DataClient visualizing processing result from Ecere Processes API using synchronous mode

Figure 9 — WHU’s OGE-DataClient visualizing processing result from WHU Processes API using Workflows&Chaining(collection output)

OpenEO API

The OGE-DataClient supports invoking processes provided by the OpenEO API in synchronous mode by creating a process graph in the JSON editor.

Figure 10 — WHU’s OGE-DataClient visualizing processing result in PNG format obtained from the rasdaman OpenEO API while operating in synchronous mode

5.2.5.3.  Future improvements

5.2.6.1.  Approach

Satellite Derived Observations for Sea Ice Albedo

A key essential variable for the Arctic is surface albedo which is a strong indicator of a warming Arctic region. The Arctic surface air temperature is rising twice as fast as the rest of the world, and Arctic sea ice is retreating up to three times faster than the rate projected by climate model simulations. The decline of sea ice and snow cover in the Arctic Ocean leads to a decrease of the surface reflection and an increase of absorption of solar radiation which in turn increases surface temperature and triggers sea ice decline. This surface albedo feedback loop is one of the major drivers of Arctic amplification and a strong indicator of a region in transition towards an ice-free environment.

Arctic Regional Reanalysis datasets at 2.5 km resolution are ingested into a rasdaman GDC instance. The dataset covers a circumpolar region including Greenland, the Labrador Sea, and the Davis Strait. This provides a baseline of spatial and temporal characteristics of the region and over which the GDC client performs regional analysis of the surface albedo for an area of interest surrounding the Ninginganiq National Wildlife Area.

As apparent, the change in albedo between the period of May 2020 and April 2023 is substantial in the southern extent while the changes specific to the Ninginganiq National Wildlife Area have remained relatively stable.

Figure 11 — Albedo as an Essential Variable of the Arctic

Environmental Data Retrieval

The D113 data client is based on the pygeoapi open source platform. The D113 data client is designed as a provider extension that transforms standard Environmental Data Retrieval (EDR) API structured queries to the GDC interface and dispatches the queries to the GDC service provider. Effectively, the GDC provider instance acts as a facade to the GDC API endpoint that provides similar capabilities including slicing, filtering, and trimming across a multi-dimensional cube.

Figure 12 — EDR provider framework

5.2.6.2.  Use Cases

Surface Albedo for the Spring Equinox 2019

This use case focuses on using a GeoDataCube API implementation to request slicing the surface albedo observations along the spatial dimensions for the region of interest at a specific time instance. The client requests the ‘albedo’ parameter from the GDC service provider given an area of interest (polygon) and time instance (datetime=2019-05-06T00:00:00.000Z).

Figure 13 — Surface albedo Spring 2019

Of note is that by implementing the EDR GDC provider as a facade to each GDC service provider, the spatial and temporal constraints may be issued to a separate GDC service provider with no impact to the client workflow. As an example, the following query requests the near-surface temperature from the Ecere GDC provider instance.

Example

Figure 14 — CMIP5 Near Surface Temperature Spring 2019

Temporal analysis of Surface Albedo

The inherent value of the GeoDataCube framework is its ability to scale both in terms of volume of data and processing capabilities. This use case focuses on delegating the analysis of surface albedo to the GDC service provider over a temporal extent to determine the magnitude of change for each gridded observation. In this case, the GDC provider translates the EDR request to compose a process graph for execution by the GDC service instance to determine the change in surface albedo for the region of interest over the temporal range of May 2019 — April 2023.

Figure 15 — Magnitude of change in surface albedo between May 2019 and April 2023

5.2.6.3.  Challenges & Future Work

EDR API

EDR, in its role as a simplified API for querying discrete coverages of observations, provides an effective means to query across the spatial and temporal dimensions of a GeoDataCube. Certain capabilities of the draft GeoDataCube API standard are abstracted away as EDR queries against a collection/instanceID where the instanceID represents a named process graph. Whether this is the intention of the OGC EDR API standard is to be further investigated as certain process graphs, especially resource intensive process graphs, require an asynchronous workflow that benefits from caching at the service layer.

The EDR query capabilities were limited to investigating area-based and cube-based queries against the GDC service instances. Further investigation into the capabilities of the GeoDataCube framework for trajectory-based and corridor-based queries, for example, would be of benefit to support further interoperability requirements with the OGC Moving Features Standard.

Response Encodings

The response encodings supported by the EDR client focused on image-based (.png), coverage-based (CoverageJSON), and multi-dimensional encodings supported by NetCDF. Further investigation into alternative file-based encodings such as Zarr and GeoParquet would likely enhance the workflow with support for cloud-optimized analysis ready data stores.

5.2.7.1.  Implementation details

This section lists the tests that the ETS currently consists of.