4.2.1.  Needs of end-users and application developers

Two main categories of users must be considered in the design of an OGC GDC API. The first category is that of end-users, such as climate researchers. These end-users are less concerned with the technical aspects of the API as they will likely be using the API indirectly through client applications. Their primary concern is that a standardized GDC API enables interoperability between multiple client applications and services providing datasets and analytics for a common baseline of functionalities meeting their needs. However, server-side OGC API implementations are also intended to be directly accessible by end-users, such as implementing an HTML representation of resources which may readily offer a minimum amount of functionality typical of a client. This should be considered in the design to ensure that it is possible to present the API in a user-friendly manner.

The second category of users is the developers. Developers, who will be using the GDC API to build client applications, are the primary users of the API. These users expect a uniform API that can be used with different services and datasets. They are concerned primarily with the API providing the functionality needed for their application. The ease with which they can learn how to access that functionality and how interoperable and efficient this functionality is in different implementations of the API is also important.

Finally, the back-end developers, although technically not users of the API, must implement the API functionality and are often concerned with the amount of effort required to understand and develop a service conforming to the API specification, with how easy it is to map each operation to their capabilities to provide access to data and analytics, and how possible it is to efficiently map this functionality.

Clearly, all of these targeted users and developers desire a convenient, simple and uniform API. Several of the OGC APIs being considered for use in the GDC API are still at a draft stage. If these draft APIs do not currently satisfy requirements for convenience, simplicity and uniformity, attempts should be made to improve them to address those needs. This approach is better than defining yet another completely distinct API that would further fragment the OGC API standards base and reduce interoperability.

4.2.2.  Requirements from sponsors

From the Testbed 17 Call for Participation, the following sponsor requirements for the Geo Data Cube API task were identified:

• Define an OGC API leveraging existing building blocks for Geo Data Cubes.

• Support access and processing in the cloud.

• Support data discovery and querying information of diverse collections of data, including spatial and temporal resolution, interoperability with STAC, registries and catalogs.

• Support interoperability of data formats and access methods: Cloud Optimized GeoTIFF which supports direct HTTP range requests, OGC WxS, OGC APIs.

• Support interoperability across different cloud providers.

• Support interoperable workflows for terrestrial & marine elevation, forestry information that can:

  • Process / extract information from forestry imagery;

  • Handle formats that enable interoperability such as for images/point clouds;

  • Derive insights & change prediction from spatiotemporal data.

• Support interoperability between different Geo Data Cubes / APIs, as well as between GDC API and offline.

• Support integration of terrestrial & marine elevation data from separate Geo Data Cubes.

• Support for integration with advanced technology such as Machine Learning.

4.2.3.  Data access

A GDC API should support accessing different types of data. Examples are data cubes for regular and irregular gridded raster data and data defined by vector features geometries of different dimensionality (including point clouds with a large number of points). The domain of the data cube should be capable of supporting one or more spatial and/or temporal dimensions, and possibly additional types of dimensions.

The values associated with a direct position in the data cube (range values in coverages terminology) should support both discrete (e.g. land cover category) and continuous (e.g. radiance) observed properties (e.g. the bands / sensor type in EO imagery).

During the GDC work in Testbed-17, some confusion was noted as to what should be presented as a field / property / value of the range vs. what should be presented as an axis of the domain. Topic 6 of the OGC Abstract Specification makes a clear distinction between the two. A dimension is part of the direct position for which values are available, and must be defined in the Coordinate Reference System (CRS) for the overall domain. Most often dimensions are limited to the spatiotemporal domain. Another use case for an additional dimension would be a parameter for which properties were observed at several different values or at a continuous range of values, throughout the other aspects (e.g. spatiotemporal) of the domain.

A data cube may itself be made up of smaller data cube pieces (e.g. imagery scenes or granules). Having the GDC API providing direct access to these scenes would be useful. This could enable an application to more accurately reflect the original data characteristics of those scenes making up the data cube. An example is supporting their native CRS (e.g. Universal Transverse Mercator (UTM) coordinate system zones in Landsat-8) while providing an easier-to-access unifying data cube for the different scenes through a single CRS and a fixed resolution.

Describing these aspects of the data and providing convenient and efficient access to it in its raw form are two key capabilities for a GDC API.

Figure 2 — Figure from openEO showing layers of a data cube across imagery bands and time axis.

4.2.3.2.  Data retrieval

A GDC API needs a simple mechanism to retrieve data in convenient encodings, without imposing a particular logical data model on those physical encodings.

Although retrieving an entire data cube as a single operation is possible, a common use case is to retrieve only a certain portion of interest. This is often a particular spatial area which also corresponds to a useful resolution (native resolution for small areas, but down-sampled for larger areas), resulting in a constant maximum response size. Support for retrieving only part of the data is critical for large collections of data for which retrieving everything is unnecessary and a waste of processing and bandwidth resources at both ends of the API, and often impractical or impossible. Such subsetting and down-sampling capability can be implemented efficiently with backing data stores supporting overviews / tile pyramids, as in Cloud Optimized GeoTIFF (COG) and Tile Matrix Sets (OGC 17-083r4). Directly exposing the multi-resolution tiles through the API to clients may improve performance by aligning requests with the data store’s internal organization, and thus enable efficient caching of responses on both the server and client side. Requesting a subset of a temporal dimension may also be a desirable capability.

In coverages terminology, a subsetting operation reducing dimensions (e.g. from 3D space + time to 2D space only) is called slicing. A subsetting operation preserving the same number of dimensions is called trimming (i.e. requesting a range of values for each axis in the subsetting operation). A GDC API may also support supersampling, but this is of less value for accessing raw data as it wastes bandwidth and processing resources, and could always be done on the client-end if necessary. However, supersampling may be necessary to present a data cube of a uniform resolution where the resolution of the data source in fact is variable.

Additionally, a client may only be interested in requesting values only for some of the range (observed properties / fields, e.g. specific imagery bands of interest).

Figure 3 — Figure from openEO illustrating data trimming by time, range subsetting (selecting a single band) and intersection with a spatial area.

Figure 4 — Figure from openEO illustrating data slicing, reducing dimensions of the data.

Figure 5 — Figure from openEO illustrating temporal resampling.

Figure 6 — Figure from openEO illustrating spatial resampling.

The participants also discussed the need for more advanced data filtering capabilities. Examples are returning only portions of the data by comparing values from particular fields (e.g. Quality of data band with cloud cover information) and/or properties of metadata (e.g. cloud cover) associated with a particular scene as a whole (for coarser but faster filtering). This is particularly useful in the context of reducing dimensionality such as when wishing to retrieve a cloud-free 2D mosaic comprised of multiple EO imagery scenes, from the same spatiotemporal data cube, which were captured closest to or before a specific slicing time.

Another use case, of particular relevance to meteorology for example, is subsetting data based on more complex patterns, such as trajectories or corridors, providing the API with a detailed geometry of the area of interest and retrieving only relevant values.

In a sense, these advanced retrieval capabilities such as filtering, re-sampling and even subsetting to some extent could be considered a form of simple analytics. They are discussed here because they still integrate well within a data retrieval request. This is because they can be expressed as simple query parameters and combined together, with the resulting response sharing many of the characteristics of a plain request for the original data.

4.2.4.  Analytics

The ability to perform data analytics close to the data is an important capability of a GDC API, improving performance, saving bandwidth, time and costs. The participants noted that the community has struggled so far in defining and adopting a simple and interoperable approach to analytics, with several implementors coming up with their own approach.

A comprehensive GDC API should cover both simple analytics such as aggregation over time or band arithmetic calculations (e.g. for vegetation index calculation), as well as more complex analytics such as prediction from machine learning.

Commonly accessed and simple to express analytics capabilities should be very simple and convenient to use.

For simple cases such as aggregation and band arithmetic calculations, it may be possible to standardize a simple language to express those aspects which could also be integrated with data retrieval requests. For slightly more complex analytics, the concept of a well-known process, standardized to expect a specific set of inputs and return a specific type of output, might be useful. Some well-known processes could be defined to expect a particular language defining the analytics to perform expressed in popular raster expression or coverage processing languages adopted by particular communities. Others could be defined to implement specific algorithms, such as calculation of the Normalized Difference Vegetation Index (NDVI) or contour generation. Other examples of well-known processes previously experimented with in the context of OGC APIs include for example calculating a route OGC 21-000 and rendering a map.

4.2.5.  Discovery

In the context of using a single API to discover and access data, a large number of data cubes may be available which could be filtered based on specific aspects (e.g. spatial or temporal extent, resolution, sensor types). Also if a single data cube is made up of several scenes, which typically also have associated metadata, it would be useful to query for scenes of interests, possibly directly integrated as part of data retrieval requests. Similarly, discovering relevant algorithms from a large set of analytics capabilities available would be very useful. Establishing which data cubes and which algorithms can be used together is also of great interest. The possibility to catalog data and algorithms, as well as provide the ability to discover relevant data and analytics capabilities, would also be very useful for end-users.

4.2.6.  Visualization

Although not an essential capability because clients can implement their own visualization capabilities with better performance and using less bandwidth, a GDC API implementation could also decide to provide access to server-side visualization capabilities. However with the ubiquity of Graphical Processing Units (GPUs) in modern hardware, leaving visualization to the client has many benefits. The HTML representation for the raw data resources of a GDC API could still incorporate visualization capabilities, without requiring the definition of those capabilities in the API itself.

4.2.7.  Managing data and algorithms

The ability to manage data and algorithms is not necessarily a capability required by end-users, especially if the GDC API supports the creation of ad-hoc workflows referencing arbitrary data sources and processes (as researched in the Modular OGC API Workflows project and defined in OGC API — Processes — Part 3). However, this is a useful capability allowing larger organization or multiple parties to manage and maintain data cubes.

5.2.1.  OGC API — Coverages

The draft OGC API — Coverages OGC 19-087 specification defines building blocks for describing and retrieving multi-dimensional data from a coverage. The Coverages API work is based on Topic 6 of the OGC Abstract Specification (ISO 19123). A common type of coverage is gridded (raster) data, but coverages are not limited to gridded data and can include, for example, point clouds.

A description of a coverage’s DomainSet always includes a Coordinate Reference System, as well as the lower and upper bound for which data can be retrieved. Coverage grids can either be spaced regularly (described by a fixed resolution for a regular axis) or irregularly (in which case positions along the irregular axis must be explicitly listed when describing the domain).

The fields (range values, e.g. the different bands available for imagery, or observed properties) available for retrieval make up the RangeType, and include a name, a semantic link and a unit of measure where applicable.

The description of the coverage’s DomainSet and RangeType are linked from the OGC API — Common collection, and can be embedded within the collection description itself by using a JSONPointer. In addition to possibly being able to retrieve the entire raw data in a single request at /coverage, additional conformance classes are defined in Part 1 — Core allowing to retrieve only the area and resolution interest.

5.2.2.  OGC API — Tiles

The draft OGC API — Tiles specification (OGC 20-057) specifies how to retrieve data on a tile-by-tile basis. The Tiles API is based on the 2D Tile Matrix Set and TileSet metadata draft specification (OGC 17-083r4), which is a revision of the 2D Tile Matrix Set Standard. With the Core conformance class of OGC API — Tiles, tiles can be retrieved according to registered TileMatrixSets using a simple URL template with three variables: a tile matrix identifier (usually a zoom level), a tile row and a tile column. The content of the tiles can be rendered map tiles, raw gridded coverage values, vector features, or other things like point clouds or 3D meshes. The TileSet conformance class adds support for describing a tileset by providing such a template, indicating limits for these variables, a link to the TileMatrixSet definition, a URI for registered TileMatrixSets, as well as additional metadata.

Having a pre-defined pyramidal tiling scheme as opposed to clients requesting arbitrary scale factors and subsetting bounds facilitates caching on both the client & server side. For example, different visualization clients panning and zooming in the same area would make the exact same fewer requests only reaching the next binary zoom level or bringing in the next 256×256 pixels tiles, as opposed to potentially making misaligned requests for their exact viewport configuration any time it changes.

5.2.3.  OGC API — Features

The OGC API — Features Standard specifies an API to retrieve vector features. Features can be retrieved individually by ID, or as a feature collection up to a certain limit beyond which pagination into multiple requests is necessary. The Core standard supports filtering by intersection with a bounding box and or a temporal range. Part 2 of OGC API — Features is also an approved standard defining supports for CRSes other than CRS84. Part 3 of OGC API — Features (OGC 19-079r1) implements filtering capabilities. Future extensions may also define the ability to create, replace, update and delete features, as well as to retrieve generalized (simplified) and clipped features.

5.2.4.  OGC API — Environmental Data Retrieval

OGC API — Environmental Data Retrieval (EDR) is an approved OGC Standard specifying multiple ways to query a data cube, including for typical meteorological use cases such as data along a trajectory or within a corridor. The Testbed-17 Participants did not implement support for the EDR API, but performed a quick comparative analysis with other OGC API specifications for accessing data cubes. EDR leverages building blocks of OGC API — Common Part 1 & 2. However some discrepancies (see EDR issues #331, #332, and #333) were identified in how the spatiotemporal extents are described which would have made it impossible to offer the same collection of data through both OGC API — EDR and other draft specification or OGC API standard (such as OGC API — Coverages, OGC API — Tiles, or OGC API — Features), unless the collection of data (data cube) is declared as a separate collection resource. As a result of those findings, the EDR SWG has corrected the standard to address most of those issues.

In order to resolve issue #332, the EDR SWG opted to introduce a property separate from interval called values to describe the DomainSet of the collection of data. OGC API — EDR also specifies a mechanism to describe the fields (RangeType) directly in the collection description, which differs from the way it is being specified in Coverages. The participants also noted that the cube query defined by OGC API — EDR overlaps greatly with the OGC API — Coverages specification and its subsetting and scaling conformance classes, and that the two could perhaps be harmonized and re-integrated, similarly to how OGC API — EDR references OGC API — Features for its items query. Although OGC API — EDR defines several types of queries, it does not define separate conformance classes for each of those queries. Splitting these into multiple conformance classes stood out as something that could facilitate testing compliance or requiring the capability for specific types of queries. Another observation was that the parameter-name query parameter supporting the selection of properties to be returned (range subsetting) could be defined the same way as properties= across OGC API — Features, OGC API — Coverages and OGC API — EDR. An issue was filed to propose changing range-subset= to properties= in Coverages. These aspects would greatly benefit from a re-alignment to maintain consistency within the OGC API family of standards, and avoid re-defining the same functionality in different ways.

5.2.5.  Data Access & Processing API (DAPA)

The Data Access & Processing API (DAPA) Engineering Report (ER) (OGC 20-025r1) provides a draft specification and documents work performed in the OGC Testbed-16 task. The DAPA ER suggests a number of different designs for accessing data cubes. This includes:

• a capability to describe the fields of a data cube, overlapping with those defined in OGC API — EDR (parameter names) and OGC API — Coverages (RangeType),

• point and area sampling capabilities, overlapping with similar capabilities in OGC API — EDR and OGC API — Coverages,

• some filtering capabilities, similar to the proposed filtering extensions for coverages,

• the ability to query for data within a specified geometry also found in OGC API — EDR queries using a geom query parameter (which could also be implemented as an extension to OGC API — Coverages as proposed in issue #52),

• the ability to select fields / observable properties to be returned also found in the other OGC APIs (those suggested to be unified as properties=), as well as

• some analytics capabilities covered in a separate section below. Rather than defining a completely separate new API, the proposed capabilities not already present in OGC API — EDR and OGC API — Coverages could instead be integrated in these core specifications or in extensions. Testbed-17 participants did not get the chance to explore DAPA in details, however Wuhan University initiated support for the API in its service.

5.2.6.  Scenes API

Large data cubes such as those resulting from Earth Observation satellites that are constantly capturing new data are often made up of individual scenes with more being added continuously. Each of these individual scenes may be stored in a different native CRS (such as UTM zones) and/or spatial resolution. The ability to present these multiple scenes as a unified data cube / coverage, while still being able to directly access the individual scenes as well would prove useful and forms the basis for proposing a Scenes API. This API would have both a data access as well as a discovery aspect (of individual scenes of interest but from within a single collection / coverage / data cube). As discussed above, preserving and exposing the metadata for these scenes as queryables would also enable integrating scene discovery directly in a data request (e.g. at /coverage), facilitating generating a cloud-free mosaic. This is an important use case for which the SpatioTemporal Asset Catalog (STAC) has been used but without this suggested level of integration. The management aspect of these scenes is discussed in a section below.

Two approaches were suggested for a Scenes API:

• One using hierarchical collections (e.g. /collections/landsat8 and /collections/landsat8:LC81400402013123LGN01), which could work with the existing /collections/{collectionId}/coverage and OGC API — Records — Part 2: Collections extension (for queries) to filter /collections, and

• One introducing /scenes/ where the coverage endpoint could be transported to /collections/{collectionId}/scenes/{sceneId}/coverage and records queries could also be made available at /collections/{collectionId}/scenes (in this case you would get back a GeoJSON list of scenes, as with STAC & OGC API — Records — Part 1: Core).

This would still make it possible to access a unified (native) CRS84 coverage at /collections/landsat8/coverage, while the native CRS for e.g. /collections/landsat8:LC81400402013123LGN01/coverage (or /collections/landsat8/scenes/LC81400402013123LGN01/coverage) would be in the original UTM zone CRS.

A Scenes API would facilitate serving while supporting the management, access and filtering of the individual scenes making up a coverage. The discovery capability could also be fully integrated within the data access itself (e.g. as a query parameter to a /coverage request). This integrated discovery / data access capability could unlock a lot of potential functionality, such as easily generating a cloud-free mosaic.

The pros and cons, as well as the challenges to resolve with each approach are as follows. None of the drawbacks are seen as showstoppers, so either approach would be suitable.

5.2.7.  OGC API — DGGS

The OGC API — DGGS draft specification (OGC 21-038) enables clients and servers understanding the same Discrete Global Grid System to exchange information in terms of that reference system, i.e. as DGGS zones. The What is here? capability of a DGGS is a data access mechanism which can return data for one or more specific DGGS zone in a compact representation which could be integrated within the GDC API framework. In addition to selecting data by explicitly listing zones, it could also be possible to specify a CQL expression and/or geometry to filter what data gets returned.

5.3.1.  OGC API — Processes — Part 1: Core

The core OGC API — Processes standard defines how an API can list and describe available processes (including their inputs and outputs), how to submit execution requests for available processes, and how to retrieve results from these processes. Processes can support synchronous and/or asynchronous execution. An execution request is a JSON document usually containing a list of inputs, and optionally a list of specific outputs to be returned. For example, inputs may be scalar parameters, spatial or spatiotemporal data. Inputs can be provided embedded into the execution requests (encoded as base64 for binary inputs) or referenced as a URL.

5.3.2.  OGC API — Processes — Part 3: Workflows & Chaining

The OGC API — Processes — Part 3 — Workflows & Chaining draft specification (OGC 21-009) defines how to chain multiple processes and data sources together, whether they are local or remote. Part 3 of OGC API — Processes also enables triggering processing on-the-fly as a result of regular data requests (e.g. OGC API — Coverages or Tiles) for a particular area and resolution of interest. This facilitates the integration of processing capabilities into visualization libraries and clients.

In addition to synchronous and asynchronous processing, the draft specification introduces a new mode of execution: the response to submitting an execution request is an OGC API landing page or collection including links to supported data access endpoints for the execution results. Clients can then submit requests to these endpoints with parameters specifying the area and resolution of interest (e.g. tile identifiers, or coverage subsetting and scaling) to both trigger processing and retrieve the response. By submitting multiple small requests (e.g. 256×256 pixels tiles) which can be requested and processed in parallel and leveraging caching along the workflow chain, real-time processing workflows are achievable.

Part 3 of OGC API — Processes also adds three new types of inputs that can be used in an execution request:

• The first new type of input is an OGC API collection (which can be local to the server or remote), that points to a data source without hardcoding a particular area, resolution or format, leaving it up to the two nodes at each end of a hop in the workflow to negotiate which to use for accessing the data, and facilitating the re-usability of a defined workflow with different data sources or area of interests.

• The second new type of input is a nested process (which can also be local or remote), which is defined as the same object as the top-level object of the execution request document.

• Finally, the third new possibility for an execution request input allows chaining an external input in the context of deploying a workflow as new opaque process.

In addition to the possibility of being deployed as new processes, workflows could also be deployed as virtual collections / data cubes, which would appear to a client as any other data cubes, except that they may additionally expose the source workflow that generates the data (which would include a reference to all processes and data sources part of the workflows), which would facilitate the re-usability and reproducibility. Another advantage of workflows is the ability to always use the latest available data without requiring batch processing but by responding to data requests while still able to support intelligent caching.

For more details on workflows, see the Flexible real-time data processing and visualization workflows emerging from OGC API modules (OGC 21-033).

5.3.3.  DAPA capabilities as Coverages and EDR extensions

The draft DAPA specification includes some pre-defined analytics capabilities such as aggregation and band arithmetic calculations. There are already plans to integrate aggregation capabilities in a future version of OGC API — EDR as well as in OGC API — Coverages. The participants suggest that instead of defining a separate API, similar aggregation capability be integrated directly in the OGC API — EDR queries and OGC API — Coverages request, in a harmonized manner, possibly with an aggregate parameter. This likely requires further investigation to address the variety of ways data can be aggregated over different dimensions. Similarly, the ability to define a new set of fields for a coverage based on a simple expression (as in derived fields proposed in DAPA) could also be available directly in OGC API — EDR queries and OGC API — Coverages requests, and could possibly use the same suggested properties= syntax. This was previously suggested for coverages here.

5.3.4.  Profiles for coverage processing

OGC API — Processes offers unlimited analytics possibilities, but it may sometimes be useful to define well-known processes expecting specific types of inputs and returning specific outputs. A particular well-known process could, for example, support a specific coverage processing language, which may be useful for more complex use cases which cannot be expressed in very simple query parameters to express filtering, aggregation or computed fields.

5.3.5.  Compatible data cubes and processes

The concept of a GeoDataClass is proposed as a mechanism to identify the compatibility of any given data cube as an input to a particular process, which may be available from separate providers. A GeoDataClass would be a URI corresponding to a particular data schema to which a data cube could ascribe. A process would be able to tag a particular input with this URI, allowing to easily identify compatible data sources which can be used for this input. For example, a GeoDataClass could be defined for an elevation data cube with a single field representing elevation in meters above the WGS84 ellipsoid, and a process generating contours could specify this URI for its single input elevation data source. Another example would be a GeoDataClass defined for Landsat-8 Collection 2 Level 2, specifying all sensor bands and their characteristics, and a land cover prediction process could tag its input with this URI as expecting such a data source.

5.3.6.  OGC API — DGGS

The Where is it? capability of the OGC API — DGGS draft specification could enable analytics queries, returning a list of DGGS zones satisfying the query. For example, this query could be expressed using CQL, which has the benefit of being reusable for performing analytics with other OGC API specifications.

7.1.1.  Open Data Cube (ODC)

ODC is an open source geospatial data management and analysis software project that supports the efficient use of earth observation data. At its core it offers uniform access to heterogeneous data sets and sources as data cubes in an analysis-ready way. Figure 13 illustrates the basic concept. Data is stored on a native file system or a cloud platform. First, the data is indexed in a PostgreSQL database with some metadata. This index is the central metadata store that allows querying and accessing data. For the indexing, metadata documents need to be prepared and registered using the datacube-core Python library (https://github.com/opendatacube/datacube-core) which is the heart of ODC. These documents are yaml files in the ODC-specific metadata format “eo3” (https://datacube-core.readthedocs.io/en/latest/about-core-concepts/dataset-documents.html#dataset-metadata-doc-eo3) or its predecessor “eo”. ODC distinguishes between products and datasets. A dataset is for example a single Landsat scene while a product is a collection of datasets. All datasets of a single product share the same measurements and some basic metadata, e.g. sensor type. In contrast, coordinate reference systems can vary among different datasets. The datacube-core library also offers a simple uniform Python API to retrieve data. Spatial, temporal and thematic (band) filtering is possible and also reprojection and down- and upsampling of the data.

Figure 13 — ODC architecture (source: https://medium.com/opendatacube/what-is-open-data-cube-805af60820d7)

ODC is continuously improved and extended by a large community. Recently, new features like 3D datasets and STAC (Spatio Temporal Asset Catalog, https://stacindex.org/) support have been added which were not available at the beginning of Testbed-17. By interfacing with a STAC API it will be possible to retrieve data without indexing it in a database beforehand (https://github.com/opendatacube/odc-stac). Some features regarding STAC can already be used, however, there isn’t a comprehensive public documentation yet.

Once data is indexed, it can be retrieved and used in applications like Jupyter Notebooks or web services. While there is already a web service implementation offering classical OGC web services (OWS) on top of ODC’s index and core library, there is — to the best of the participants’ knowledge — no service implementation offering OGC APIs.

7.1.2.  pygeoapi

pygeoapi is a Python server implementation of the OGC API family of standards. It offers a core Python API and an HTTP API on top of it. Publishing of data is organized with a provider framework. Providers implement the logic of handling specific data resources, e.g. geotiff files or databases, and return data to the pygeoapi API framework. Every resource (collections, processes, catalogs) which is served needs to be configured with a suitable provider.

7.1.3.  Service architecture

52°North’s service implementation builds on ODC and pygeoapi. ODC serves as a Geo Data Cube resource and is responsible for storing and managing data and metadata. pygeoapi uses this resource and publishes the included data via OGC APIs. The connection between ODC and pygeoapi is achieved by a provider plugin for pygeoapi called pygeoapi-odc-provider (https://github.com/52North/pygeoapi-odc-provider), which has been developed by 52°North in this Testbed. The basic service architecture is shown in Figure 14 and explained in more detail in the following.

Figure 14 — Architecture of 52°North’s service implementation

Data is first downloaded from various platforms, stored in a file system and added to the metadata index using ODC. The process of downloading and indexing data was automatized for NRCan’s DEM datasets and for Landsat 8 Collection 2 Level 2 data (https://github.com/52North/ogc-tb-17_datacube-service_odc/tree/main/downloader, make repo public). It is also possible to add custom metadata under the “metadata” key in the product definition (see example yaml) and parse these later to complete pygeoapi’s resource configuration. 52°North added product, provider, project, category, links and keywords. An example for a product definition for NRCan’s DEM data is presented in the following. It provides Digital Surface Model (DSM) data collected during the project “The Pas” in 2014:

metadata_type: eo3
name: dsm__MB__The_Pas_2014
description: '"dsm" data created by "MB" within the project "The_Pas_2014"'
metadata:
  product:
    name: dsm__MB__The_Pas_2014
  provider:
    name: MB
  project:
    name: The_Pas_2014
  category:
    name: dsm
  keywords:
  - MB
  - The_Pas_2014
  - dsm
  - NRCAN
  - Canada
  links:
  - type: text/html
    rel: canonical
    title: High Resolution Digital Elevation Model (HRDEM) - CanElevation Series
    href: https://open.canada.ca/data/en/dataset/957782bf-847c-4644-a757-e383c0057995
    hreflang: en-CA
measurements:
- name: dsm
  units: m
  dtype: float32
  nodata: -32767.0

A dataset for this product looks like this:

$schema: https://schemas.opendatacube.org/dataset
id: e8dc8680-08d8-5aa5-a05c-70c2f9b85ee9
product:
  name: dsm__MB__The_Pas_2014
provider:
  name: MB
project:
  name: The_Pas_2014
category:
  name: dsm
keywords:
- MB
- The_Pas_2014
- dsm
- NRCAN
- Canada
links:
- type: text/html
  rel: canonical
  title: High Resolution Digital Elevation Model (HRDEM) - CanElevation Series
  href: https://open.canada.ca/data/en/dataset/957782bf-847c-4644-a757-e383c0057995
  hreflang: en-CA
crs: EPSG:2957
geometry:
  type: Polygon
  coordinates:
  - - - 710000.0
      - 5940000.0
    - - 710000.0
      - 5950000.0
    - - 720000.0
      - 5950000.0
    - - 720000.0
      - 5940000.0
    - - 710000.0
      - 5940000.0
grids:
  default:
    shape:
    - 10000
    - 10000
    transform:
    - 1.0
    - 0.0
    - 710000.0
    - 0.0
    - -1.0
    - 5950000.0
    - 0
    - 0
    - 1
measurements:
  dsm:
    path: /ogc-tb-17/DATA/dsm/MB/The_Pas_2014/dsm_1m_utm13_e_21_194.tif
    layer: dsm
properties:
  datetime: '1970-01-01T00:00:00+00:00'
  platform: na
  instrument: na
  odc:processing_datetime: '2021-09-22T14:28:57+00:00'
  odc:file_format: GeoTIFF
  odc:product_family: dsm__MB__The_Pas_2014
  dea:dataset_maturity: final
  providers:
  - MB
  mission: The_Pas_2014
lineage: {}

Once ODC is set up, the connection between ODC and pygeoapi has to be established. The new pygeoapi provider plugin pygeoapi-odc-provider facilitates this. It implements all the logic of retrieving metadata and data using ODC’s Python API and maps it to the specific OGC API. For OGC API — Coverages, it maps ODC products to OGC coverage collections. These two concepts are similar and the mapping is relatively straightforward. To finally use ODC in pygeoapi, it is necessary to configure the resources with the correct provider class. A resource entry for a coverage collection in pygeoapi`s configuration file looks like this:

dsm__MB__The_Pas_2014:
    type: collection
    title: dsm__MB__The_Pas_2014
    description: '"dsm" data created by "MB" within the project "The_Pas_2014"'
    keywords:
    - MB
    - The_Pas_2014
    - dsm
    - NRCAN
    - Canada
    links:
    - type: text/html
      rel: canonical
      title: High Resolution Digital Elevation Model (HRDEM) - CanElevation Series
      href: https://open.canada.ca/data/en/dataset/957782bf-847c-4644-a757-e383c0057995
      hreflang: en-CA
    extents:
      spatial:
        bbox:
        - -101.88198091547551
        - 53.491466538566925
        - -101.04177012496181
        - 53.94941224261376
        crs: http://www.opengis.net/def/crs/OGC/1.3/CRS84
    providers:
    - type: coverage
      name: odcprovider.OpenDataCubeCoveragesProvider
      data: dsm__MB__The_Pas_2014
      format:
        name: GeoTIFF
        mimetype: application/geotiff

The data field in the provider section corresponds to the product name in ODC. The name field declares the provider class implementation. The pygeoapi-odc-provider library also provides a script to automatically generate a configuration file for pygeoapi including resource entries for all ODC products.

The service is deployed in the cloud using kubernetes. It consists of two pods: a database (image: postgres:13-buster with 10Gi storage) and a service pod created from a 52°North image (https://github.com/52North/ogc-tb-17_datacube-service_odc/blob/main/pygeoapi/Dockerfile). The data is currently stored on persistent volume claims. Using the s3 capabilities of ODC is a useful next step in the development of the provider, but could not be fulfilled during this testbed. The datasets (see Section Clause 7.1.4.1) are downloaded using two init-containers sharing the same storage volume. During this download process, each dataset is enriched with the required metadata documents and added to the ODC index.

7.1.4.  API Structure

• Service root

  • Collections

    • Catalog collection providing records, which provides links to

      • Items

        • List of items with properties in html, json, ld-json

          • Item with properties, e.g. associations (aka links) to the coverage itself in the three formats html, json, ld-json

      • Queryables (not implemented)

      • Different formats as html, json, ld-json

    • For each product in the ODC one collection with

      • Bounding box on map

      • Keywords

      • Links from links metadata

      • Links to

        • Collection as html, json, ld-json

        • Domain set as html, json, ld-json

        • Coverage Domain as html, json, ld-json

        • Coverage data, e.g. as GeoTIFF

  • Processes

    • Described in Machine Learning within a Geo Data Cube API

7.1.5.  Specific challenges

7.2.1.  GDC definition from Wuhan University perspective

A geospatial data cube is defined as a time-series multidimensional data model, where multi-source geospatial data can be organized as spatially aligned analysis ready data in a high-performance form. The multi-source geospatial data is not limited to EO data such as remote sensing images, but also can be the vector, trajectory, or tabular data.

7.2.2.  Deployment infrastructure

The Wuhan deployment relies on the GeoCube infrastructure. The infrastructure is established on a private cloud environment comprising three physical servers. These servers are connected to a high-performance storage array of PB level.

The GeoCube infrastructure supports the accommodation of multi-source geospatial data including raster and vector data in the cube, these data are segmented into tiles and persisted in an HBase database, which allows a user to perform efficient multi-source data analysis using a high-performance tile form. In the infrastructure, cloud computing technology such as Apache Spark is used to enable large-scale analysis for cube tiles.

7.2.3.  Datasets

• Landsat-8 L1TP

• NRCAN DEM

• Gaofen-1

• OpenStreetMap

Please note: The API might not work with every dataset. The API has been tested successfully with Landsat-8 L1TP.

7.2.4.  Coverages API Implementation

This implementation establishes how to access data cube through the official WHU GDC endpoint http://geos.whu.edu.cn:8097/geocube/gdc_api_v2/

This section lists some examples of how to access the data cube using the implemented Geo Data Cube API.

Example: /collections

http://geos.whu.edu.cn:8097/geocube/gdc_api_v2/collections?limit=10&bbox=112.65942,29.23223,115.06959,31.36234&time=2016-08-30T02:55:50Z/2018-08-30T02:55:50Z

The API endpoint for retrieving dataset collections. Query parameters including limit, bbox, and time can be used.

This returns a list of collections in the data cube. The response is shown below.

{
    "collections": [
        {
            "id": "NRCAN_DEM_ARD_EO_19780101080000",
            "title": "DEM_ARD",
            "description": "Satellite images of DEM",
            "extent": {
                "spatial": [
                    -95.0,
                    76.4450135938,
                    -55.6861621295,
                    85.1591224444
                ],
                "temporal": [
                    "1978-01-01T08:00:00Z"
                ]
            },
            "crs": [
                "http://www.opengis.net/def/crs/OGC/1.3/CRS84",
                "http://www.opengis.net/def/crs/EPSG/0/4326"
            ],
            "links": [
                {
                    "href": "/geocube/gdc_api_v2/collections/NRCAN_DEM_ARD_EO_19780101080000",
                    "rel": "self",
                    "type": "application/json",
                    "title": "NRCAN_DEM_ARD_EO_19780101080000(as PNG; Note: requesting large extent may result in generalized data)"
                },
                {
                    "href": "/geocube/gdc_api_v2/collections/NRCAN_DEM_ARD_EO_19780101080000/coverage?f=png",
                    "rel": "http://www.opengis.net/def/rel/ogc/1.0/coverage",
                    "type": "image/png",
                    "title": "NRCAN_DEM_ARD_EO_19780101080000(as PNG; Note: requesting large extent may result in generalized data)"
                },
                {
                    "href": "/geocube/gdc_api_v2/collections/NRCAN_DEM_ARD_EO_19780101080000/coverage?f=tif",
                    "rel": "http://www.opengis.net/def/rel/ogc/1.0/coverage",
                    "type": "image/tiff; application=geotiff",
                    "title": "NRCAN_DEM_ARD_EO_19780101080000(as geoTiff; Note: requesting large extent may result in generalized data)"
                },
                {
                    "href": "/geocube/gdc_api_v2/collections/NRCAN_DEM_ARD_EO_19780101080000/coverage/domainset",
                    "rel": "http://www.opengis.net/def/rel/ogc/1.0/coverage-domainset",
                    "type": "application/json",
                    "title": "NRCAN_DEM_ARD_EO_19780101080000(domain set of the coverage for this collection)"
                },
                {
                    "href": "/geocube/gdc_api_v2/collections/NRCAN_DEM_ARD_EO_19780101080000/coverage/rangetype",
                    "rel": "http://www.opengis.net/def/rel/ogc/1.0/coverage-rangetype",
                    "type": "application/json",
                    "title": "NRCAN_DEM_ARD_EO_19780101080000(range type of the coverage for this collection)"
                }
            ]
        },
        {
            "id": "LC08_L1TP_ARD_EO_20171217025629",
            "title": "Landsat8_ARD",
            "description": "Satellite images of Landsat8",
            "extent": {
                "spatial": [
                    112.62546,
                    29.23323,
                    115.03488,
                    31.36008
                ],
                "temporal": [
                    "2017-12-17T02:56:29Z"
                ]
            },
            "crs": [
                "http://www.opengis.net/def/crs/OGC/1.3/CRS84",
                "http://www.opengis.net/def/crs/EPSG/0/4326"
            ],
            "links": [
                {
                    "href": "/geocube/gdc_api_v2/collections/LC08_L1TP_ARD_EO_20171217025629",
                    "rel": "self",
                    "type": "application/json",
                    "title": "LC08_L1TP_ARD_EO_20171217025629(as PNG; Note: requesting large extent may result in generalized data)"
                },
                {
                    "href": "/geocube/gdc_api_v2/collections/LC08_L1TP_ARD_EO_20171217025629/coverage?f=png",
                    "rel": "http://www.opengis.net/def/rel/ogc/1.0/coverage",
                    "type": "image/png",
                    "title": "LC08_L1TP_ARD_EO_20171217025629(as PNG; Note: requesting large extent may result in generalized data)"
                },
                {
                    "href": "/geocube/gdc_api_v2/collections/LC08_L1TP_ARD_EO_20171217025629/coverage?f=tif",
                    "rel": "http://www.opengis.net/def/rel/ogc/1.0/coverage",
                    "type": "image/tiff; application=geotiff",
                    "title": "LC08_L1TP_ARD_EO_20171217025629(as geoTiff; Note: requesting large extent may result in generalized data)"
                },
                {
                    "href": "/geocube/gdc_api_v2/collections/LC08_L1TP_ARD_EO_20171217025629/coverage/domainset",
                    "rel": "http://www.opengis.net/def/rel/ogc/1.0/coverage-domainset",
                    "type": "application/json",
                    "title": "LC08_L1TP_ARD_EO_20171217025629(domain set of the coverage for this collection)"
                },
                {
                    "href": "/geocube/gdc_api_v2/collections/LC08_L1TP_ARD_EO_20171217025629/coverage/rangetype",
                    "rel": "http://www.opengis.net/def/rel/ogc/1.0/coverage-rangetype",
                    "type": "application/json",
                    "title": "LC08_L1TP_ARD_EO_20171217025629(range type of the coverage for this collection)"
                }
            ]
        },
        ...
    ]
}

Example: /collections/{collectionId}

http://geos.whu.edu.cn:8097/geocube/gdc_api_v2/collections/LC08_L1TP_ARD_EO_20171217025629

The API endpoint for describing the data cube collection “LC08_L1TP_ARD_EO_20171217025629”.

The response is shown below.

{
    "id": "LC08_L1TP_ARD_EO_20171217025629",
    "title": "Landsat8_ARD",
    "description": "Satellite images of Landsat8",
    "extent": {
        "spatial": [
            112.62546,
            29.23323,
            115.03488,
            31.36008
        ],
        "temporal": [
            "2017-12-17T02:56:29Z"
        ]
    },
    "crs": [
        "http://www.opengis.net/def/crs/OGC/1.3/CRS84",
        "http://www.opengis.net/def/crs/EPSG/0/4326"
    ],
    "links": [
        {
            "href": "/geocube/gdc_api_v2/collections/LC08_L1TP_ARD_EO_20171217025629",
            "rel": "self",
            "type": "application/json",
            "title": "LC08_L1TP_ARD_EO_20171217025629(as PNG; Note: requesting large extent may result in generalized data)"
        },
        {
            "href": "/geocube/gdc_api_v2/collections/LC08_L1TP_ARD_EO_20171217025629/coverage?f=png",
            "rel": "http://www.opengis.net/def/rel/ogc/1.0/coverage",
            "type": "image/png",
            "title": "LC08_L1TP_ARD_EO_20171217025629(as PNG; Note: requesting large extent may result in generalized data)"
        },
        {
            "href": "/geocube/gdc_api_v2/collections/LC08_L1TP_ARD_EO_20171217025629/coverage?f=tif",
            "rel": "http://www.opengis.net/def/rel/ogc/1.0/coverage",
            "type": "image/tiff; application=geotiff",
            "title": "LC08_L1TP_ARD_EO_20171217025629(as geoTiff; Note: requesting large extent may result in generalized data)"
        },
        {
            "href": "/geocube/gdc_api_v2/collections/LC08_L1TP_ARD_EO_20171217025629/coverage/domainset",
            "rel": "http://www.opengis.net/def/rel/ogc/1.0/coverage-domainset",
            "type": "application/json",
            "title": "LC08_L1TP_ARD_EO_20171217025629(domain set of the coverage for this collection)"
        },
        {
            "href": "/geocube/gdc_api_v2/collections/LC08_L1TP_ARD_EO_20171217025629/coverage/rangetype",
            "rel": "http://www.opengis.net/def/rel/ogc/1.0/coverage-rangetype",
            "type": "application/json",
            "title": "LC08_L1TP_ARD_EO_20171217025629(range type of the coverage for this collection)"
        }
    ]
}

Example: /collections/{collectionId}/coverage

http://geos.whu.edu.cn:8097/geocube/gdc_api_v2/collections/LC08_L1TP_ARD_EO_20171217025629/coverage

http://geos.whu.edu.cn:8097/geocube/gdc_api_v2/collections/LC08_L1TP_ARD_EO_20171217025629/coverage?f=tif&bbox=114.21,30.37,114.41,30.57&rangeSubset=Red,SWIR1,Coastal,Pan,Near-Infrared

http://geos.whu.edu.cn:8097/geocube/gdc_api_v2/collections/LC08_L1TP_ARD_EO_20171217025629/coverage?f=png&subset=Lon(114.23:114.45)&scale-factor=3

The API endpoint for accessing a data cube. Query parameters including format(png,geotiff), bbox, subset,rangeSubset,scale-size,scale-axes,scale-factor.

This returns true color png or mutli-band geotiff of the coverage according to the in specified area, bands, size and scale.

Example: /collections/{collectionId}/coverage/rangetype

http://geos.whu.edu.cn:8097/geocube/gdc_api_v2/collections/LC08_L1TP_ARD_EO_20171217025629/coverage/rangetype

The API endpoint for accessing cube range type.

This returns the range type of the multi-band coverage as the dimensions of the cube.

{
    "type": "DataRecord",
    "field": [
        {
            "type": "Quantity",
            "name": "SWIR1",
            "description": "SWIR1 channel",
            "uom": {
                "type": "UnitReference",
                "code": "1"
            },
            "encodingInfo": {
                "dataType": "http://www.opengis.net/def/dataType/OGC/0/float32"
            }
        },
        {
            "type": "Quantity",
            "name": "Coastal",
            "description": "Coastal channel",
            "uom": {
                "type": "UnitReference",
                "code": "1"
            },
            "encodingInfo": {
                "dataType": "http://www.opengis.net/def/dataType/OGC/0/float32"
            }
        },
        {
            "type": "Quantity",
            "name": "Blue",
            "description": "Blue channel",
            "uom": {
                "type": "UnitReference",
                "code": "1"
            },
            "encodingInfo": {
                "dataType": "http://www.opengis.net/def/dataType/OGC/0/float32"
            }
        },
        {
            "type": "Quantity",
            "name": "Cirrus",
            "description": "Cirrus channel",
            "uom": {
                "type": "UnitReference",
                "code": "1"
            },
            "encodingInfo": {
                "dataType": "http://www.opengis.net/def/dataType/OGC/0/float32"
            }
        },
        {
            "type": "Quantity",
            "name": "Red",
            "description": "Red channel",
            "uom": {
                "type": "UnitReference",
                "code": "1"
            },
            "encodingInfo": {
                "dataType": "http://www.opengis.net/def/dataType/OGC/0/float32"
            }
        },
        {
            "type": "Quantity",
            "name": "Green",
            "description": "Green channel",
            "uom": {
                "type": "UnitReference",
                "code": "1"
            },
            "encodingInfo": {
                "dataType": "http://www.opengis.net/def/dataType/OGC/0/float32"
            }
        },
        {
            "type": "Quantity",
            "name": "Near-Infrared",
            "description": "Near-Infrared channel",
            "uom": {
                "type": "UnitReference",
                "code": "1"
            },
            "encodingInfo": {
                "dataType": "http://www.opengis.net/def/dataType/OGC/0/float32"
            }
        },
        {
            "type": "Quantity",
            "name": "Pan",
            "description": "Pan channel",
            "uom": {
                "type": "UnitReference",
                "code": "1"
            },
            "encodingInfo": {
                "dataType": "http://www.opengis.net/def/dataType/OGC/0/float32"
            }
        },
        {
            "type": "Quantity",
            "name": "SWIR2",
            "description": "SWIR2 channel",
            "uom": {
                "type": "UnitReference",
                "code": "1"
            },
            "encodingInfo": {
                "dataType": "http://www.opengis.net/def/dataType/OGC/0/float32"
            }
        }
    ]
}

Example: /collections/{collectionId}/coverage/domainset

http://geos.whu.edu.cn:8097/geocube/gdc_api_v2/collections/LC08_L1TP_ARD_EO_20171217025629/coverage/domainset

The API endpoint for accessing cube domain set.

This returns the domain set of a coverage.

{
    "type": "DomainSet",
    "generalGrid": {
        "type": "GeneralGridCoverageType",
        "srsName": "http://www.opengis.net/def/crs/OGC/1.3/CRS84",
        "axisLabels": [
            "Lon",
            "Lat"
        ],
        "axis": [
            {
                "type": "RegularAxis",
                "axisLabel": "Lon",
                "lowerBound": 112.62546,
                "upperBound": 115.03488,
                "resolution": 27.5
            },
            {
                "type": "RegularAxis",
                "axisLabel": "Lat",
                "lowerBound": 29.23323,
                "upperBound": 31.36008,
                "resolution": 27.5
            }
        ],
        "gridLimits": {
            "type": "GridLimits",
            "srsName": "http://www.opengis.net/def/crs/OGC/0/Index2D",
            "axisLabels": [
                "i",
                "j"
            ],
            "axis": [
                {
                    "type": "IndexAxisType",
                    "axisLabel": "i",
                    "lowerBound": 0.0,
                    "upperBound": 15999.0,
                    "resolution": null
                },
                {
                    "type": "IndexAxisType",
                    "axisLabel": "j",
                    "lowerBound": 0.0,
                    "upperBound": 11999.0,
                    "resolution": null
                }
            ]
        }
    }
}

7.2.5.  Processes API Implementation

This implementation establishes how to perform analysis on a data cube through the implemented GDC API.

This section lists some examples.

Example: /processes

http://geos.whu.edu.cn:8097/geocube/gdc_api_v2/processes

The API endpoint for retrieving the processes list.

This returns a list of processes implemented in the GeoCube. The response is shown below.

[
    {
        "id": "aspect",
        "title": "aspect",
        "version": "1.0.0",
        "jobControlOptions": [
            "async-execute"
        ],
        "outputTransmission": [
            "value",
            "reference"
        ],
        "links": [
            {
                "href": "/geocube/gdc_api_v2/processes/aspect",
                "rel": "self",
                "type": "application/json",
                "title": "process description"
            }
        ]
    },
    {
        "id": "slope",
        "title": "slope",
        "version": "1.0.0",
        "jobControlOptions": [
            "async-execute"
        ],
        "outputTransmission": [
            "value",
            "reference"
        ],
        "links": [
            {
                "href": "/geocube/gdc_api_v2/processes/slope",
                "rel": "self",
                "type": "application/json",
                "title": "process description"
            }
        ]
    },
    {
        "id": "ndvi",
        "title": "ndvi",
        "version": "1.0.0",
        "jobControlOptions": [
            "async-execute"
        ],
        "outputTransmission": [
            "value",
            "reference"
        ],
        "links": [
            {
                "href": "/geocube/gdc_api_v2/processes/ndvi",
                "rel": "self",
                "type": "application/json",
                "title": "process description"
            }
        ]
    },
    {
        "id": "ndwi",
        "title": "ndwi",
        "version": "1.0.0",
        "jobControlOptions": [
            "async-execute"
        ],
        "outputTransmission": [
            "value",
            "reference"
        ],
        "links": [
            {
                "href": "/geocube/gdc_api_v2/processes/ndwi",
                "rel": "self",
                "type": "application/json",
                "title": "process description"
            }
        ]
    }
]

Example: /processes/{processId}

http://geos.whu.edu.cn:8097/geocube/gdc_api_v2/processes/ndwi

The API endpoint for retrieving a process description (e.g. ndwi).

This returns the description of “ndwi” process. The response is shown below.

{
    "id": "ndwi",
    "title": "ndwi",
    "version": "1.0.0",
    "jobControlOptions": [
        "async-execute"
    ],
    "outputTransmission": [
        "value",
        "reference"
    ],
    "inputs": {
        "rasterProductName": {
            "title": "raster input",
            "schema": {
                "type": "string",
                "default": "LC08_L1TP_ARD_EO"
            },
            "minOccurs": 1,
            "maxOccurs": 1
        },
        "extent": {
            "title": "extent",
            "description": "Bounding box of the extent to process",
            "schema": {
                "allOf": [
                    {
                        "format": "ogc-bbox"
                    },
                    {
                        "$ref": "https://raw.githubusercontent.com/opengeospatial/ogcapi-processes/master/core/openapi/schemas/bbox.yaml"
                    }
                ],
                "default": {
                    "bbox": [
                        113.3,
                        30.5,
                        113.5,
                        30.7
                    ],
                    "crs": "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
                }
            },
            "minOccurs": 0,
            "maxOccurs": 1
        },
        "startTime": {
            "title": "startTime",
            "schema": {
                "type": "string",
                "default": "2017-01-01"
            },
            "minOccurs": 1,
            "maxOccurs": 1
        },
        "endTime": {
            "title": "endTime",
            "schema": {
                "type": "string",
                "default": "2018-01-01"
            },
            "minOccurs": 1,
            "maxOccurs": 1
        }
    },
    "outputs": {
        "ndwiResult": {
            "title": "NDWI Result",
            "description": "Normalize Difference Water Index",
            "schema": {
                "oneOf": [
                    {
                        "type": "string",
                        "contentEncoding": "binary",
                        "contentMediaType": "image/tiff; application=geotiff"
                    },
                    {
                        "type": "string",
                        "contentEncoding": "binary",
                        "contentMediaType": "image/png"
                    }
                ]
            }
        }
    },
    "links": [
        {
            "href": "geocube/gdc_api_v2/processes/ndwi/execution",
            "rel": "http://www.opengis.net/def/rel/ogc/1.0/execute",
            "title": "NDWI Execute endpoint"
        }
    ]
}

Example: /processes/{processId}/execute

http://geos.whu.edu.cn:8097/geocube/processes_api/processes/ndwi/execution

The API endpoint for creating a new job.

Request body example:

{
   "process" : "http://geos.whu.edu.cn:8097/geocube/gdc_api_v2/processes/ndwi",
   "inputs" : {
      "rasterProductName" : "LC08_L1TP_ARD_EO",
      "startTime" : "2017-01-01",
      "endTime" : "2018-01-01",
      "extent" : {
         "bbox" : [ 114.3, 30.5, 114.5, 30.7 ],
         "crs" : "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
      }
   }
}

The response is as follows:

{
    "jobID": "60fe95e1-a077-40fe-b05e-346bd6373880",
    "progress": 40,
    "links": {
        "href": "/geocube/gdc_api_v2/processes/ndwi/jobs/60fe95e1-a077-40fe-b05e-346bd6373880",
        "rel": "self",
        "type": "application/json",
        "title": "ndwi"
    },
    "type": "processes",
    "message": "Process is running",
    "status": "running"
}

Example: /processes/{processId}/jobs/{jobId}

http://geos.whu.edu.cn:8097/geocube/gdc_api_v2/processes/ndwi/jobs/{jobId}

The API endpoint for retrieving status of a job, which retrieves same returns as the above.

Example: /processes/{processId}/jobs/{jobId}/results

http://geos.whu.edu.cn:8097/geocube/gdc_api_v2/processes/ndwi/jobs/{jobId}/results

The API endpoint for retrieving results of a job, which are encoded as follows:

[
    {
        "id": "2017_01_24",
        "value": {
            "inlineValue": "/geocube/gdc_api_v2/results/view/F59E2F8CE40897CFB03CA50512096317/60fe95e1-a077-40fe-b05e-346bd6373880/NDWI_2017_01_24.png"
        }
    },
    {
        "id": "2017_12_17",
        "value": {
            "inlineValue": "/geocube/gdc_api_v2/results/view/F59E2F8CE40897CFB03CA50512096317/60fe95e1-a077-40fe-b05e-346bd6373880/NDWI_2017_12_17.png"
        }
    },
    {
        "id": "2017_08_27",
        "value": {
            "inlineValue": "/geocube/gdc_api_v2/results/view/F59E2F8CE40897CFB03CA50512096317/60fe95e1-a077-40fe-b05e-346bd6373880/NDWI_2017_08_27.png"
        }
    }
]

7.2.6.  Geo Data Cube (GDC) API design

• /collections: to get the list of GDC instances. Each cube instance is described by multi-dimensions including extent, time range, list of available products, and resolution if it is a raster product. The products can contain various datasets like raster data, vector data, and point cloud data. These cube instances can be filtered by the dimensions.

• /collections/{cubeID}: to describe the cube. Returns the dimension information of the cube. Continuous dimension (e.g. space and time) is comprised by a range, while discrete dimension (e.g. product and resolution) consists of a list of discrete members.

• /collections/{cubeID}/coverage: to access data from the collection using OGC API — Coverages.

• /collections/{cubeID}/processes: to perform analytics functions using OGC API — Processes.

• /collections/{cubeID}/dapa: to get the list of available data retrieval patterns including (based on DAPA): for example

  • /collections/{cubeID}/dapa/area:aggregate + dimension: space,time,product,resolution (aggregate along these dimensions)

  • /collections/{cubeID}/dapa/position:aggregate + dimension: time,product,resolution (aggregate along these dimensions)

The following endpoints are specific to the Wuhan University implementation:

• /collections/{cubeID}/dimensions: to describe the shared dimensions formalizing that cube, which can be space, time, product, theme and so on.

• /collections/{cubeID}/sources: to describe the data sources composing that cube, which can be a variety of products.

• /collections/{cubeID}/cells: to get the list of cells/facts in the cube, each cell contains a measure (single pixel/point or collection of pixels/points) which is characterized by the dimensions. These cells can be filtered by the dimensions (product, space, time, and theme), allowing multi-dimensional subsetting.

• /collections/{cubeID}/cells/{cellId}: to get the detailed information of one particular cell/fact in the cube.

7.3.1.  MEEO Server Endpoint

https://testbed17.adamplatform.eu/datacube/api/v0

7.3.2.  Idea for a Geo Data Cube

The idea behind the MEEO Geo Data Cube service is to index the datasets (data) suggested in the CFP, and to expose a series of services per datasets, namely: discovery (e.g. OGC API — Records or equivalent), access (e.g. OGC API — Tiles or equivalent) and processing (e.g. OGC API — Processes or equivalent).

The idea is not to define a closed list of services and standards, but rather to provide human/machine readable services to support the exploitation of the data.

7.3.3.  Geo Data Cube discovery

https://testbed17.adamplatform.eu/datacube/api/v0/datasets

This API provides the list of datasets indexed in the Geo Data Cube instance.

7.3.4.  Geo Data Cube dataset fetch

https://testbed17.adamplatform.eu/datacube/api/v0/datasets/CA_harvest_year

This API provides details about the dataset = datasetID (e.g. CA_harvest_year), including description and services.

In the description subdocument, all the information about geolocation, time range, data type, etc. can be found.

In the services subdocument all the enabled services can be found.

7.3.5.  Geo Data Cube dataset Records API

https://testbed17.adamplatform.eu/datacube/api/v0/datasets/CA_harvest_year/search

This API exposes the discovery service to list the actual resources (i.e. raster) available for the dataset {datasetID} (e.g. CA_harvest_year).

This API relies on the OpenSearch conformance class, with Geo and Time extensions.

7.3.6.  Geo Data Cube dataset Tiles API

https://testbed17.adamplatform.eu/datacube/api/v0/datasets/CA_harvest_year/tiles/gist_rainbow_mpl;nodata=0.000000;colorrange=(0.000000,115.000000)/1984-12-31T00:00:00Z/1985-01-01T00:00:00Z/EPSG:3857/9/157/171.png

This API exposes the access and visualization services for exploiting the actual resources (i.e. raster data) available for the dataset `{datasetID} (e.g. CA_harvest_year).

This API relies on the Dataset Tile Sets conformance class, for what concerns the Style, and on the Geo Data Resource Selection conformance class, for what regards Tiles.

7.4.1.  Elevation datasets

Elevation datasets from NRCan’s HRDEM of the Red River area in Manitoba, and of the Ottawa river were loaded onto Ecere’s OGC API demonstration server.

Figure 16 — NRCan HRDEM for Red River area in Manitoba at 1 and 2 m resolution rendered by Ecere’s GNOSIS Map Server

Figure 17 — NRCan HRDEM for Ottawa river area rendered by Ecere’s GNOSIS Map Server

Bathymetry datasets from CHS NONNA, were also loaded for resolutions of 10 m (partial dataset) and 100 m (whole dataset).

Figure 18 — CHS NONNA at 10m resolution rendered by Ecere’s GNOSIS Map Server

Figure 19 — CHS NONNA at 100m resolution rendered by Ecere’s GNOSIS Map Server

In the following screenshot, both terrestrial elevation from the HRDEM and bathymetry from the 10 m NONNA are accessed and visualized together in Ecere’s GNOSIS Cartographer client.

Figure 20 — HRDEM from RedRiver and CHS NONNA at 10m resolution visualized accessed from Ecere’s GNOSIS Map Server and visualized in GNOSIS Cartographer

7.4.2.  Coverages API Implementation

The server implements support for OGC API — Coverages, including the subsetting and scaling conformance classes. Efforts were spent during the initiative to enable the ability to serve multi-band data cubes made up of multiple scenes such as Landsat-8 imagery. However, these capabilities, which will also support range subsetting and the proposed Scenes API capability, remain to be completed.

The following query URL demonstrates accessing raw values from an elevation data cube served by Ecere’s OGC API demonstration server sourced from a high resolution Digital Elevation Model provided by NRCan, downsampled (by a factor of 2) and subset along both the latitude and longitude axes, using the Coverages API as a GeoTIFF.

Downsampled and subset coverage request

https://maps.ecere.com/ogcapi/collections/HRDEM-Ottawa/coverage?scale-factor=2&subset=Lat(45.44:45.47),Lon(-75.7:-75.6)&f=geotiff

The following URLs point to the collection description resource for this data cube, which itself provides a link to the description of the domain and range, which in this case are also available separately.

https://maps.ecere.com/ogcapi/collections/HRDEM-Ottawa

https://maps.ecere.com/ogcapi/collections/HRDEM-Ottawa/coverage/domainset?f=json

https://maps.ecere.com/ogcapi/collections/HRDEM-Ottawa/coverage/rangetype?f=json

The server also supports a prototype of what a CRS extension could look like, based on an approach similar to OGC API — Features — Part 2. For example, the following returns the same coverage projected as World Mercator (EPSG:3395) rather than the default in Plate carrée (EPSG:4326):

https://maps.ecere.com/ogcapi/collections/HRDEM-Ottawa/coverage?crs=epsg:3395&scale-factor=8&f=tiff

7.4.3.  Processes API Implementation

Ecere’s GNOSIS Map Server supports OGC API — Processes — Part 1: Core using synchronous execution. The Map Server also supports the draft Part 3: Workflows & Chaining specification allowing first setting up an execution of an individual process or a workflow, and then triggering execution for an area and resolution of interest, and retrieval of the result in a negotiated format. The retrieval can be done using OGC API — Tiles regardless of whether the result of the execution is a coverage, a collection of vector features or a map, or using OGC API — Features, Coverages or Maps depending on the type of output. If the result of the execution is vector data, requests can still be made using OGC API — Maps or Tiles which will additionally trigger server side rendering of the output.

A list of processes is available at the https://maps.ecere.com/ogcapi/processes end-point.

Process description example

https://maps.ecere.com/ogcapi/processes/RFClassify?f=json

Requesting the RFClassify process description will return the following JSON response.

{
  "id" : "RFClassify",
  "title" : "Random Forest Classification",
  "version" : "1.0.0",
  "jobControlOptions": [
    "sync-execute", "workflow-collection"
  ],
  "outputTransmission" : [ "value" ],
  "description" : "This process outputs a random-forest classified image using imagery and training feature dataset",
  "links" : [ {
    "href" : "https://maps.ecere.com/ogcapi/processes/RFClassify/execution",
    "rel" : "http://www.opengis.net/def/rel/ogc/1.0/execute",
    "title" : "Execution endpoint"
  } ],
  "inputs" : {
   "data" :
    {
      "title" : "The data set",
      "description" : "The collection containing the imagery for the randomforest process.",
      "minOccurs" : 1,
      "maxOccurs" : 1,
      "schema" : {
        "oneOf": [
          {
            "type": "string",
            "contentEncoding": "binary",
            "contentMediaType": "image/tiff; application=geotiff"
          },
          {
            "type": "string",
            "contentEncoding": "binary",
            "contentMediaType": "image/png"
          }
        ]
      }
    }
  },
  "outputs" : {
    "classification" :
    {
      "title" : "Classified image",
      "description" : "Classified image",
      "schema" : {
        "oneOf": [
          {
            "type": "string",
            "contentEncoding": "binary",
            "contentMediaType": "image/tiff; application=geotiff"
          },
          {
            "type": "string",
            "contentEncoding": "binary",
            "contentMediaType": "image/png"
          }
        ]
      }
    }
  }
}

Process execution

A process execution is submitted at /processes/{processId}/execution for synchronous execution. At the publication date of this ER, a separate endpoint (/processes/{processId}) was used to set up a workflow and retrieve a description of the resulting virtual collection. In the future, this capability will likely move to the same /execution endpoint, differentiated from a regular synchronous or asynchronous execution request by using a query parameter to request a collection description or landing page to be returned.

Inputs to the process are specified as part of the execution request. All defined outputs are returned by default, if not explicitly including an “outputs” section in the request. The HTML representation of the process endpoint provides a form to easily submit an execution request. For example, the following request can be submitted to the RenderMap process located at https://maps.ecere.com/ogcapi/processes/RenderMap:

{
   "process" : "https://maps.ecere.com/ogcapi/processes/RenderMap",
   "inputs" : {
      "background" : "navy",
      "transparent" : false,
      "layers" : [
         { "collection" : "https://maps.ecere.com/ogcapi/collections/CHSBathymetryNONNA100" },
         { "collection" : "https://maps.ecere.com/ogcapi/collections/CHSBathymetryNONNA10" }
      ]
   }
}

Upon execution the output is generated and exists as a temporary virtual collection, e.g. …​/ogcapi/scratch/31FDA020. These can be accessed and used like any other collection.

7.4.4.  Tiles API Implementation

The server supports vector and coverage data as well as map tiles.

The tile URL template for coverages is:

/collections/{collectionID}/coverage/tiles/{tileMatrixSetId}/{tileMatrix}/{tileRow}/{tileCol}.{format}

Multiple tiling schemes are supported. This example requests the HRDEM-Ottawa coverage tiles as GeoTIFF with the WebMercatorQuad tiling scheme.

HRDEM-Ottawa coverage tiles

https://maps.ecere.com/ogcapi/collections/HRDEM-Ottawa/coverage/tiles/WebMercatorQuad/13/2931/2374.tif

The request for the same dataset as map tiles would be as follows:

HRDEM-Ottawa map tiles

https://maps.ecere.com/ogcapi/collections/HRDEM-Ottawa/map/tiles/WebMercatorQuad/13/2931/2374.png

8.1.1.  Scope and functional Focus

The client can connect to different data back-ends and uses the same API client implementation for all of them. In the course of the thread described in this ER, various flavors of a Data Cube API were discussed. Consequently, the servers may implement specific subsets or deviate in certain aspects from the REST resource structure that this GDC client expects.

The TIE experiments were thus focused on covering the basics such as initial connection, collection discovery, and metadata retrieval for all servers. Ideally, access to the data provided by resources is then available in a systematic fashion, where the URL pattern / template is part of the metadata and allows the client to retrieve the tiles of the resource independent of the server’s implementation.

8.1.2.  Goal and Challenges

The following goals and challenges were tackled with the development of this client:

• The client API should be as uniform as possible, allowing connection to different servers that provide the standard API endpoints (landing page, collection enumeration, links to those collections).
  A connection should be possible to any server that provides these basic endpoints.

• The GDC API is not strictly defined yet and could potentially contain data in any OGC format (e.g. coverages, features, records, etc).
  

  • Response formats should be supported for the demonstrator to a reasonable degree, i.e. not necessarily with all depth that the standard has to offer but with enough functionality that the concept can be shown. Accordingly, the client’s development was started with using other OGC APIs and consuming their respective responses in order to visualize them and adapted to use the correct resource URLs and requests specific to the GDC API.

  • Servers that deviate too far from the majority consensus of presenting data may not be supported. There is not enough time to implement multiple extensive client libraries.

• The servers should support HTTPS, as the demonstrator is hosted on an HTTPS server and HTTP resources are considered insecure and will be blocked.

• The GDC API should support tiling / sub-setting / mip-mapping of data in order to fetch reasonable sized partial resources to overlay on the globe.

  • Reasonable size means 1-3x the final rendered size at a particular zoom level. A little bit of oversampling is ok and manageable, but gigabyte-sized images or vector collections are not.

  • Reasonable size for images / raster data means common OpenGL texture buffer sized images, e.g. 1024×1024 — 4096×4096 (depending on hardware and driver support. The lower bound limit might be preferred for resource constrained environments.)

Larger images need to be tiled either way in order to render them on screen. Preferably, this tiling is already done at the data source. Even though it is possible to do more complex processing of downloaded files, to retrieve specific slices of a file and to do more complex processing in a browser, it is not an efficient use of resources. A more efficient approach in terms of processing power is to pre-compute results on the server and provide them via a Tiling capability on the server instead of downloading gigabytes of data into a resource constrained browser environment, possibly via slow internet connection, to then possibly discard most of it to render the visible pixels on screen.

Figure 22 — WebWorldWind client visualizing elevation data from the 52°North GDC API

8.1.3.  Implementation

A Typescript API was generated using the OpenAPI specification from Ecere’s server implementation. This generated API provides Typescript bindings for maps, coverages and processes. The client application written in Angular uses the API to retrieve data and displays it on the WebWorldWind globe.

Figure 23 — WebWorldWind client visualizing processing results from Ecere GDC API using Workflows & Chaining (collection output)

The following functionality is implemented on the client:

• Retrieving list of collections

• Defining bounding box

• Defining time using a time slider

• “Play” button to automatically move the time forward

• Rendering output PNG or GeoTIFF on the globe

• Retrieving list of processes

• Defining process input as JSON

• Executing process synchronously

• Rendering process output PNG on the globe

• Retrieving heightmap data (SRTM_ViewFinderPanorama from Ecere API)

Figure 24 — WebWorldWind demonstrator application showing successful Coverages TIE with Wuhan University GDC API

Figure 25 — WebWorldWind demonstrator application showing successful Coverages TIE with Wuhan University GDC API at a smaller scale

8.1.4.  Future improvements

The following improvements are recommended for implementation in future testbeds:

• Visualizing CoverageJSON data

• Asynchronous process execution

• Band subsetting

• Scaling

• UI for defining heightmap inputs

8.2.1.  Scope and functional Focus

The client can connect to any service that uses the draft Geo Data Cube API definition. As this initial definition is still rather provisional, and there has been some debate on how exactly a GDC service differs from the Coverages API, the client implements only a subset of the potential endpoints considered over the course of the testbed. With this in mind, the goal was to implement example data-visualizations that make use of each of the draft implementations of the GDC API. Subsequently the TIE testing for this client focused on a key subset of the possible endpoints described in the initial GDC API. The client can render visualizations using various data-types which may be served via GDC, including OpenSceneGraph (OSG) native, but also GeoTIFF (.tif) and glTF binary format (.glb).

8.2.2.  Implementation goals

The Ethar client was built with the following goals in mind:

• To create a geospatial data visualization tool specifically for an Augmented Reality context.

• To create a visualization environment that can make use of and integrate traditional geospatial data formats alongside new and emerging formats that are purpose-built for AR and VR applications (such as supporting both established formats like GeoTIFF and emerging formats such as glTF).

• To promote open and interoperable tooling by demonstrating the potential for a device-agnostic geospatial data visualization client for AR-enabled devices.

• Initially the participants proposed that the Ethar client would implement support for the Spatial Discovery Service (SDS) and the draft OGC GeoPose specification. These are emerging draft standards for Augmented Reality which might nicely compliment that functionality of a Geo Data Cube service. However, as testbed work progressed, it became apparent that these feature additions were premature (especially in the case of SDS).

  • The GeoPose approach was initially proposed by Ethar as a means of querying for data present in a Geo Data Cube. However, after some discussion, it was determined that GeoPose limits the scope of a query based on orientation (and potentially field-of-view).

  • GeoPose may still be useful as part of records submitted to a Geo Data Cube Service, such as a dataset describing the current position of field-workers actively connected to a GDC service.

• To demonstrate augmented reality contexts that could be useful both on-site and off-site. Thus two discrete ‘modes’ were implemented;

  • An ‘in-situ’ mode where data visualizations are scaled to align against the real-world as a field-worker might see it while on-site.

  • A ‘tabletop’ mode where data-visualizations are scaled for off-site planning purposes.

8.2.3.  Implementation

The Ethar client is implemented using a suite of web-friendly technologies. The client is written primarily with JavaScript and C/C++. These very different languages can work in concert thanks to WebAssembly, and some of the experimental WebXR features now present in select web-browsers. To maximize the varieties of geospatial data the client can support the OpenSceneGraph library is used.

The following functionality is implemented on the client:

• Retrieving a list of n-dimensional data associated with a given location.

• Exploring change over time via a slider input control.

• Visualizing GeoTIFF or glTF datasets.

8.2.4.  Future improvements

The following improvements are recommended for implementation in future testbeds:

• Visualizing additional common geospatial data formats in an Augmented Reality context.

• Interfacing with additional data APIs besides the preliminary Geo Data Cube API definition.

• Support additional web-browsers/hardware-platforms:

  • Safari and Firefox for macOS/iOS

  • Helio for Magic Leap

  • Firefox Reality for XR1/XR2 platforms (e.g. Oculus, HTC, Pico VR, etc)

• Additional User Interface components:

  • Scaling

  • Heightmap variables

  • Expanded Pan, Tilt, Zoom, Rotate (PTZR) controls

8.3.1.  Coverages API Implementation

The client is capable of requesting and rendering coverages from OGC API endpoints, with support for subsetting, range subsetting and scaling conformance classes. The coverage data can be styled by either assigning band (fields) values to red, green, blue or alpha channels with the option to perform band arithmetic calculations, or as a single channel for which a colormap and/or hillshading can be applied.

In the Testbed 17 Geo Data Cube API task, successful Coverages TIEs were achieved with services provided by 52°North and Wuhan University. In previous projects and code sprints, the client could also successfully visualize data cubes served by the EuroDataCube and by rasdaman using the Coverages API.

Accessing and visualizing data cubes using the Coverages API

The following screenshot is visualizing the 10-meter resolution bathymetry from CHS NONNA hosted by Ecere’s GNOSIS Map Server at https://maps.ecere.com/ogcapi/collections/CHSBathymetryNONNA10.

Figure 27 — Ecere’s GNOSIS Cartographer client visualizing 10-meter resolution bathymetry from CHS NONNA

The following screenshots demonstrate visualizing data cubes provided by 52°North’s GDC API implementation at https://17.testbed.dev.52north.org/geodatacube/.

Figure 28 — Ecere’s Cartographer client visualizing Landsat-8 imagery from 52°North Coverages implementation

Figure 29 — Ecere’s Cartographer client visualizing Landsat-8 imagery as NDVI from 52°North Coverages implementation

Figure 30 — Ecere’s Cartographer client visualizing Digital Terrain Model from 52°North Coverages implementation

The following screenshot demonstrates visualizing a data cube provided by Wuhan University’s GDC API implementation at http://geos.whu.edu.cn:8097/geocube/gdc_api_v2/.

Figure 31 — Ecere’s Cartographer client visualizing Landsat-8 from Wuhan University’s Coverages implementation

The following screenshot demonstrates initial progress listing the data cubes available from MEEO’s OGC API — Common implementation at https://testbed17.adamplatform.eu/datacube/api/v0 .

Figure 32 — Ecere’s Cartographer client accessing MEEO’s OGC API implementation

8.3.2.  Processes API Implementation

GNOSIS Cartographer’s workflow editor allows a user to access an OGC API — Processes instance and discover the list of available processes that can be executed either stand-alone or as part of a workflow. Inputs and parameters can be configured with the user interface, or directly crafting the execution request in a JSON editor. Executing the workflow adds the output as a data source which can be visualized by the client in the viewport. Virtual collections resulting from a workflow, as implemented in Ecere’s GNOSIS Map Server, can also be directly added as data sources without the client having to submit an execution request.

Executing processes and workflows

Pictured below is workflow configuration of a contour generation process executed on Ecere’s GNOSIS Map Server and its output visualized as vector tiles in GNOSIS Cartographer. The processing is performed on demand and on a tile-by-tile basis, considering the area and resolution of interest.

Figure 33 — Configuration of workflow using GUI tool in Cartographer client to process HRDREM-Ottawa dataset elevation contours

Figure 34 — Visualizing vector lines output of contour generation process

The following screenshot shows the workflow dialog accessing the Wuhan University’s Processes implementation.

Figure 35 — Accessing Wuhan University Processes Implementation in Workflow Editor

The following screenshot shows the workflow dialog accessing the 52°North’s Processes implementation.

Figure 36 — Accessing 52°North Processes Implementation in Workflow Editor

8.3.3.  Tiles API Implementation

The client may request tiles of vector features or coverage values and render them client-side, or request and display map tiles pre-rendered or rendered server-side.

Visualization of map tiles and vector tiles

Figure 37 — Visualizing of HRDEM-Ottawa as map tiles

Figure 38 — Visualizing HRDEM-Ottawa-LinesContours as vector tiles

Figure 39 — Visualizing map tiles from MEEO service’s CA_harvest_year data cube, together with NASA’s Blue Marble Next Generation, SRTM elevation from Jonathan de Ferranti’s View Finder Panoramas and ESA’s Gaia Sky in Color

9.3.1.  Recommendations relating to OGC API — Coverages and extensions

• The draft OGC API — Coverages specification was demonstrated as a relatively simple access mechanism for data cubes. This API can also be implemented with a minimum amount of effort on top of various data cube technologies. Support for both the subsetting and scaling conformance classes leveraging a multi-resolution data store was identified as key capabilities to adequately support large data cubes. Because overlapping functionality for describing and accessing data cubes was defined in OGC API — EDR and the Testbed 16 — DAPA specification with an argument for additional convenience, the perceived inconvenience of the Coverages API should be re-evaluated, corrections made if necessary, and the possibility of defining extensions providing the convenience or required capabilities directly in the Coverages API should be considered. Completing the standardization of Part 1 of OGC API — Coverages should be an important priority.

• A greatly simplified and better modularized future version of the Coverage Implementation Schema (CIS) should be considered as suggested here.

• Defining extensions to the SWE Common DataRecord fields, used in the Coverage Implementation Schema and OGC API — Coverages for describing the RangeType, for providing information for statistics (e.g. min and max values) and encoding information (e.g. offsets and scale factors).

9.3.2.  Recommendations relating to OGC API — Tiles and Cloud Optimized GeoTIFF

• The value of the OGC API — Tiles specification in providing pre-defined multi-resolution tile pyramids of raw data values (e.g. coverage tiles) was identified as important. Completing the standardization of Part 1 of OGC API — Tiles should be a priority.

• A conformance class of Coverages for integrating HTTP range access to a Cloud Optimized GeoTIFF representation of a coverage resource should be investigated.

• The use of Cloud Optimized GeoTIFF and/or TileMatrixSets pyramids as a backing data store to support the subsetting and scaling conformance classes of Coverages should be considered in implementations.

9.3.3.  Harmonization of OGC API data cube access

• Implementing support for the OGC API — EDR standard should be considered when the particular types of queries it defines are desired as access mechanisms.

• The compatibility issues between OGC API — EDR and OGC API — Common (as well as other OGC API specifications leveraging Common) in terms of the description of the spatiotemporal extent should be corrected so as to allow providing a particular collection using OGC API — EDR as well as other OGC API specifications.

• The overlapping functionality between the OGC API — Coverages draft specification and the OGC API — EDR standard, particularly in how they both provide mechanisms to describe the domain and range of a data cube and requesting a subset of a data cube, should be considered for a potential re-alignment and harmonization.

• The OGC process for ensuring a harmonized set of complementary OGC API standards should be re-evaluated to avoid occurrences of re-defining the same capability with only superficial variation in different standards of the OGC API family, which reduces interoperability by introducing a significant burden on implementers of clients & services in terms of additional standards to implement.

• The draft OGC API — DGGS specification should be completed and considered for integration within a Geo Data Cube API.

9.4.1.  Recommendations relating to OGC API — Processes and extensions

• The draft OGC API — Processes — Part 2: Deploy, Replace, Update specification should be completed to enable deploying analytics capabilities close to the data.

• The concept of a GeoDataClass URI to indicate the compatibility of a particular data cube as an input to a process should be investigated.

• The value of OGC API — Processes — Part 3: Workflows and Chaining supporting presentation of the results of analytics capabilities as a virtual data cube was demonstrated as facilitating the integration of analytics capabilities in visualization clients, as well as facilitating the integration of remote data cubes with processing algorithms. Completing its standardization should be an important priority.

• Defining well-known processes expecting specific inputs including a particular convenient processing language to facilitate flexible coverage processing should be considered.

9.4.2.  Recommendations relating to OGC API — Coverages, OGC API — EDR and DAPA

• Extensions to OGC API — Coverages for filtering based on CQL expressions, for specifying simple band arithmetic expressions for fields to return, for different types of aggregation based on some of the dimensions, and for support for varying resolution across a data cube should be considered.

• The functionality defined in the Testbed 16 — DAPA draft specification, such as for aggregation and derived field expressions, should be considered for integration directly within the OGC API — EDR and/or OGC API — Coverages specifications or as extensions, rather than defining yet another completely separate specification.