1.1.  Abbreviated terms

ACDC

Atmospheric Composition Data Cube

ACDD

Attribute Convention for Data Discovery

ACIS

Applied Climate Information System

ADES

Application Deployment and Execution Service

ADS

Atmosphere Data Store

AP

Application Package

API

Application Programming Interface

AR

Assessment Report

ARD

Analysis Ready Data

ARDC

Analysis Ready Data Cube

AWS

Amazon Web Service

BCSD

Bias Corrected Spatially Downscaled

BRDF

Bidirectional Reflectance Distribution Function

C3S

Copernicus Climate Change Service

CCI

Climate Change Initiative

CDI

Combined Drought Indicator

CDR

Climate Data Record

CDS

Climate Data Store

CEOS

Committee on Earth Observation Satellites

CF

Climate and Forecast

CGMS

Coordination Group for Meteorological Satellites

CIOOS

Canadian Integrated Ocean Observing System

CMIP

Coupled Model Intercomparison Project

CMR

Common Metadata Repository

CMRA

Climate Mapping for Resilience and Adaptation

COG

Cloud Optimized Geotiff

CRIS

Climate Resilience Information System

CRMA

Climate Mapping for Resilience and Adaptation

CSV

Comma-Separated Values

CWIC

CEOS WGISS Integrated Catalog

DEM

Digital Elevation Model

DRI

Decision Ready Indicator

DSW

Drought Severity Workflow

DWG

Domain Working Group

ECMWF

European Centre for Medium-Range Weather Forecasts

ECV

Essential Climate Variable

EDR

Environmental Data Retrieval

EFFIS

European Forest Fire Information System

EMS

Exploitation Platform Management Service

EO

Earth Observation

ER

Engineering Report

ERA5

fifth generation ECMWF atmospheric reanalysis of the global climate

ESA

European Space Agency

ESDC

Earth System Data Cube

ESDL

Earth System Data Laboratory

ESIP

Earth Science Information Partners

EUMETSAT

European Organisation for the Exploitation of Meteorological Satellites

FAIR

Findable, Accessible, Interoperable, Reusable

FAPAR

Fraction of Absorbed Photosynthetically Active Radiation

FME

Feature Manipulation Engine

FOSS4G

Free and Open Source Software for Geospatial

FRP

Fire Radiant Power

FWI

Fire Weather Index

GCM

General Circulation Model

GCOS

Global Climate Observing System

GDO

Global Drought Observatory

GDP

Gross Domestic Product

GHG

Greenhouse Gasses

GML

Geography Markup Language

GMU

George Mason University

GOOS

Global Ocean Observing System

GRACE

Gravity Recovery and Climate Experiment

HDF

Hierarchical Data Format

IFC

International Finance Corporation

IHO

International Hydrographic Organization

IMGW

Institute of Meteorology and Water Management⁴

IOOS

Integrated Ocean Observing System

IoT

Internet of Things

IPCC

Intergovernmental Panel on Climate Change

JRC

Joined Research Center

JSON

JavaScript Object Notation

KML

Keyhole Markup Language

LCRS

Laboratory for Climatology and Remote Sensing

LDN

Land Degradation Neutrality

LOCA

Localized Constructed Analogs

MERRA

Modern Era Retrospective-Analysis for Research and Applications

ML/AI

Machine Learning / Artificial Intelligence

MODIS

Moderate Resolution Imaging Spectroradiometer

MSDI

Marine Spatial Data Infrastructures

NASA

National Aeronautics and Space Administration

NCA4

National Climate Assessment 4

NCAR

National Center for Atmospheric Research

NDVI

Normalized Difference Vegetation Index

NDWI

Normalized Difference Water Index

NetCDF

Network Common Data Form

NOAA

National Oceanic and Atmospheric Administration

NRCan

Natural Resources Canada

OGC

Open Geospatial Consortium

OGE

Open Geospatial Engine

OMSv3

OGC Observations & Measurements 3.0

OPeNDAP

Open-source Project for a Network Data Access Protocol

OSM

OpenStreetMap

QGIS

Quantum Geographic Information System

RCI

Regional Climate Indicator

RCM

Regional Climate Model

RCP

Representative Concentration Pathway

REST

Representational State Transfer

S3

Simple Storage Service

SDG

Sustainable Development Goal

SMA

Soil Moisture Anomaly

SPEI

Standardized Precipitation Evapotranspiration Index

SPI

Standardized Precipitation Index

SQL

Structured Query Language

SR

Surface Reflectance

SSL

Secure Sockets Layer

STAC

SpatioTemporal Asset Catalogs

THREDDS

Thematic Real-time Environmental Distributed Data Services

TIE

Technical Interoperability Experiments

UNFCCC

United Nations Framework Convention on Climate Change

URL

Uniform Resource Locator

USGS

United States Geological Survey

VIIRs

Visible Infrared Imaging Radiometer Suite

WCS

Web Coverage Service

WFV

Wide Field View

WG Climate

Joint Working Group on Climate

WGISS

Working Group on Information Systems and Services

WHI

Wildland-Human Interface

WHU

Wuhan University

WMS

Web Map Service

WPS

Web Processing Service

WUI

Wildland-Urban Interface

XML

Extensible Markup Language

2.1.  The goal of the pilot

The goal of this pilot was to enable decision makers (scientists, city managers, politicians, etc.) in taking the relevant actions to address climate change and make well informed decisions for climate change adaptation. Since no single organization has all the data needed to understand the consequences of climate change, this pilot shows how to use data from multiple organizations—​available at different scales for large and small areas—​in scientific processes, analytical models, and simulation environments. The aim was to demonstrate visualization and communication tools used to craft the message in the best way for any client. Many challenges can be met through resources that adhere to FAIR (Findable, Accessible, Interoperable, and Reusable) principles. The OGC Climate Resilience Pilot identifies, discusses, and develops these resources.

The goal was to help the location community develop more powerful visualization and communication tools to accurately address ongoing climate threats such as heat, drought, floods, and fires as well as supporting nationally determined targets for greenhouse gas emission reduction. Climate resilience is often considered the use case of our lifetime; the OGC community is uniquely positioned to accelerate solutions through collective problem solving with this initiative.

Figure 1 — Value chain from raw data to climate information

As illustrated, large sets of raw data from multiple sources require further processing in order to be used for analysis and climate change impact assessments. Applying data enhancement steps, such as bias adjustments, re-gridding, or calculation of climate indicators and essential variables creates “Decision Ready Indicators.” The spatial data infrastructures required for this integration should be designed with interoperable application packages following FAIR data principles. Heterogeneous data from multiple sources can be enhanced, adjusted, refined, or quality controlled to provide Science Services data products for Climate Resilience. The OGC Climate resilience pilot also illustrates the graphical exploration of the Decision Ready Indicators and effectively demonstrates how to design FAIR climate resilience information systems underpinning FAIR Climate Services. The OGC Pilot participants illustrate the necessary tools and the visualizations to address climate actions moving towards climate resilience.

The vision of the OGC Climate Resilience Community is to support efforts on climate actions, enable international partnerships (SDG 17), and move towards global interoperable open digital infrastructures providing climate resilience information on demand by users. This pilot contributes to establishing an OGC climate resilience concept store for the community where all appropriate climate information to build climate resilience information systems as open infrastructures can be found in one place, be it information about data services, tools, software, or handbooks, or a place to discuss experiences and needs. It covers all phases of Climate Resilience from initial hazards identification and mapping, vulnerability and risk analysis, options assessments, prioritization, and planning, to implementation planning and monitoring capabilities. These major challenges can only be met through the combined efforts of many OGC members across government, industry, and academia.

2.2.  Objectives

This Pilot set the stage for a series of follow up activities and focuses on use-case development, implementation, and exploration. It also answers the following questions.

• What use-cases can be realized with the data, services, analytical functions, and visualization capabilities currently available? Current data services include, for example, the Copernicus Services, including Climate Data Store (CDS) https://cds.climate.copernicus.eu/ and Atmosphere Data Store (ADS) https://ads.atmosphere.copernicus.eu/.

• How much effort is required to realize these use-cases?

• What is missing, or needs to be improved, in order to transfer the use-cases developed in the pilot to other areas?

The pilot had three objectives:

• to better understand what is currently possible with the available data and technology;

• to determine what additional data and technology need to be developed in the future to better meet the needs of the Climate Resilience Community; and

• to capture Best Practices and allow the Climate Community to copy and transform as many use-cases as possible to other locations or framework conditions.

2.3.  Background

With growing local communities, an increase in climate-driven disasters, and an increasing risk of future natural hazards, the demand for National Resilience Frameworks and Climate Resilience Information Systems (CRISs) cannot be overstated. CRISs are enabling data-search, -fetch, -fusion, -processing, and -visualization enabling access, understanding, and use of federal data, facilitating integration of federal and state data with local data, and serving as local information hubs for climate resilience knowledge sharing.

CRISs already exist and are operational, such as the Copernicus Climate Change Service with the Climate Data Store. CRIS architectures can be further enhanced by providing scientific methods and visualization capabilities as climate application packages. Based on FAIR principles, these application packages enable the reusability of CRIS features and capabilities. Reusability is an essential component when goals, expertise, and resources are aligned from the national to the local level. Framework conditions differ across nations, but application packages enable as much reuse of existing Best Practices, tools, data, and services as possible.

Goals and objectives of decision makers vary at different scales. At the municipal level, leaders and citizens directly face climate-related hazards. Aspects thus come into focus, such as reducing vulnerability and risk, building resilience through local measures, or enhancing emergency response. At the state level, the municipal efforts can be coordinated and supported by providing funding and enacting relevant policies. The national, federal, and international levels provide funding, data, and international coordination to enable the best analyses and decisions at the lower scales.

Figure 2 — Schematic synergies within different climate and science services FAIR and open infrastructures

Productivity and decision making are enhanced when climate application packages are exchangeable across countries, organizations, or administrative levels (see Figure 2). This OGC Climate Resilience Pilot is a contribution towards an open, multi-level infrastructure that integrates data spaces, open science, and local-to-international requirements and objectives. It contributes to the technology and governance stack that enables the integration of data including historical observations, real time sensing data, reanalyses, forecasts, and future projections. It addresses data-to-decision pipelines, data analyses, and representation, and bundles everything in climate resilience application packages. These application packages are complemented by Best Practices, guidelines, and cook-books that enable multi–stakeholder decision making for the good of society in a changing natural environment.

The OGC Innovation Program brings all of the various groups together: members of the stakeholder groups define use cases and requirements; the technologists and data providers experiment with new tools and data products in an agile development process; and the scientific community provides results in appropriate formats and enables open science by providing applications that can be parameterized and executed on demand.

Figure 3 — The OGC Climate Resilience DWG and Pilot brings the climate resilience community together with infrastructure providers, policy makers, commercial companies, and the scientific community

This OGC Climate Resilience Pilot is part of the OGC Climate Community Collaborative Solution and Innovation process, an open community process that uses OGC as the governing body for collaborative activities among all members. A spiral approach is applied to connect technology enhancements, new data products, and scientific research with community needs and framework conditions at different scales. The spiral approach defines real world use cases, identifies gaps, produces new technology and data, and tests these against the real world use cases before entering the next iteration. Evaluation and validation cycles alternate and continuously define new work tasks. These tasks include documentation and toolbox descriptions on the consumer side, and data and service offerings, interoperability, and system architecture developments on the producer side. It is emphasized that research and development is not constrained to the data provider or infrastructure side. Many tasks need to be executed on the data consumer side in parallel and then merged with advancements on the provider side in regular intervals.

Good results have been achieved using OGC API standards in the past. For example, the remote operations on climate simulations (roocs) use OGC API Processes for subsetting data sets to reduce the data volume being transported. Other systems use OGC STAC for metadata and data handling or OGC Earth Observation Exploitation Platform Best Practices for the deployment of climate application packages into CRIS architectures. Still, data handling regarding higher complex climate impact assessments within FAIR and open infrastructures needs to be enhanced. There is no international recommendation or best practice on usage of existing API standards within individual CRISs. It is the goal of this pilot to contribute to the development of such a recommendation, respecting existing operational CRISs already in service.

Figure 4 — Schematic Architecture of a Climate Resilience Information System. By respecting FAIR principles for the climate application packages the architecture enables open infrastructures to produce and deliver information on demand of the users needs

2.4.  Technical Challenges

Realizing the delivery of Decision Ready Data on demand to achieve Climate Resilience involves a number of technical challenges that have already been identified by the community. A subset will be selected and embedded in use-cases that will be defined jointly by Pilot Sponsors and the OGC team. The goal is to ensure a clear value-enhancement pipeline as illustrated in Figure 1, above. This includes, among other elements, a baseline of standardized operators for data reduction and analytics. These need to fit into an overall workflow that provides translation services between upstream model data and downstream output — basically from raw data to analysis-ready data to decision-ready data.

The following technical challenges have been identified and will be treated in the focus areas of the pilot.

• Big Data Challenge: Multiple obstacles still exist which create barriers for seamless information delivery starting from Data Discovery. The emergence of new data platforms, processing functionalities, and products means that data discovery remains a challenge. In addition to existing solutions based on established metadata profiles and catalog services, new technologies such as OGC’s Spatio-Temporal Asset Catalog (STAC) and open Web APIs such as OGC API Records will be explored. Furthermore, aspects of Data Access need to be solved where the new OGC API suite of Web APIs for data access, subsetting, and processing are currently utilized very successfully in several domains. Several code sprints have shown that server-side solutions can be realized within days and clients can interact very quickly with these server endpoints, radically reducing development time. A promising specialized candidate for climate data and non-climate data integration has been recently published in the form of the OGC API — Environmental Data Retrieval (EDR). But which additional APIs are needed for climate data? Is the current set of OGC APIs sufficiently qualified to support the data enhancement pipeline illustrated in Figure 1? If not, what modifications and extensions need to be made available? How do OGC APIs cooperate with existing technologies such as THREDDS and OPEnDAP? For challenges of data spaces, Data Cubes have recently been explored in the OGC Data Cube workshop. Ad hoc creation and embedded processing functions have been identified as essential ingredients for efficient data exploration and exchange. Is it possible to transfer these concepts to all stages of the processing pipeline? How can users scale both ways from local, ad hoc cubes to pan-continental cubes, and vice versa? How can cubes be extended as part of data fusion and data integration processes?

• Cross-Discipline Data Integration: Different disciplines such as Earth Observation, various social sciences, or climate modeling use different conceptual models in their data collection, production, and analytical processes. How can these different models be mapped? What patterns have been used to transform conceptual models to logical models and, eventually, physical models? The production of modern Decision-ready information requires the integration of several data sets, including census and demographics, further social science data, transportation infrastructure, hydrography, land use, topography and other data sets. This pilot cycle uses ‘location’ as the common denominator between these diverse data sets which works with several data providers and scientific disciplines. In terms of Data Exchange Formats, the challenge is to know what data formats need to be supported at the various interfaces of the processing pipeline. What is the minimum constellation of required formats to cover the majority of use cases? What role do container formats play? Data Provenance is also challenging on the technical level. Many archives include data from several production cycles, such as IPCC AR 5 and AR 6 models. In this context, long term support needs to be realized and full traceability from high level data products back to the original raw data. Especially in context of reliable data based policy, clear audit trails and accountability for the data to information evolution must be ensured.

• Application packages for processing pipelines: Machine Learning and Artificial Intelligence plays an increasing role in the context of data science and data integration. This focus area evaluates the applicability of machine learning models in the context of the value-enhancing processing pipeline. What information needs to be provided to describe machine learning models and corresponding training data sufficiently to ensure proper usage at various steps of the pipeline? Upcoming options to deploy ML/AI within processing APIs to enhance climate services are rising challenges, e.g., on how to initiate or ingest training models and the appropriate learning extensions for the production phase of ML/AI. Heterogeneity in data spaces can be bridged with Linked Data and Data Semantics. Proper and common use of shared semantics is essential to guarantee solid value-enhancement processes. At the same time, resolvable links to procedures, sampling and data process protocols, and used applications will ensure transparency and traceability of decisions and actions based on data products. What level is currently supported? What infrastructure is required to support shared semantics? What governance mechanisms need to be put in place?

2.5.  Relevance to the Climate Resilience Domain Working Group

The Climate Resilience DWG will concern itself with technology and technology policy issues, focusing on geospatial information and technology interests as related to climate mitigation and adaptation, as well as the means by which those issues can be appropriately factored into the OGC standards development process.

The mission of the Climate Resilience DWG is to identify geospatial interoperability issues and challenges that impede climate action, then examine ways in which those challenges can be met through the application of existing OGC Standards, or through development of new geospatial interoperability standards under the auspices of OGC.

Activities to be undertaken by the Climate Resilience DWG include, but are not limited to:

• identify the OGC interface standards and encodings useful to apply FAIR concepts to climate change services platforms;

• liaise with other OGC Working Groups (WGs) to drive standards evolution;

• promote the use of the aforementioned standards with climate change service providers and policy makers addressing international regional and local needs;

• liaise with external groups working on technologies relevant to establishing ecosystems of EO Exploitation Platforms;

• liaise with external groups working on relevant technologies;

• publish OGC Technical Papers, Discussion Papers, or Best Practices on interoperable interfaces for climate change services; and

• provide software tool kits to facilitate the deployment of climate change services platforms.

2.6.  Value Chain from raw data to Information

During this pilot, participants have worked on a number of workflows and architectures focusing on several use cases of floods, droughts, heatwaves, and fires. It required the use of Climate Resilience Information Systems where interoperability played a vital role in producing climate information by enabling seamless integration and exchange of information between data, models, and various components.

The value chain from raw data to climate information (Figure 1) can be clustered in sections according to the value quality. This value chain, often also compared to a conveyor belt, can be designed with different component workflows which are developed, analyzed, and described in this pilot. The order of the chapters of the document reflects value chain organizing and processing starting from Raw data to Datacubes (Chapter 3). The following Chapter 4 describes the data refinement from Raw Data and Datacubes to Analysis Ready Data (ARD). Various data pipelines are considered and evaluated on how best to move raw data, first to data cubes for efficient handling, and then how to process them to ARD, or derive the ARD directly from the raw data. This guides the discussion on the standardization of Data Cubes and ARD. Subsequently, Chapter 5, illustrates how to transform ARD to Decision Ready Indicator (DRI) by including an example set of climate indices. The pilot also demonstrates the value added of high-end 3D visualization combined with artificial-intelligence-enriched simulations for increasing climate resilience and for facilitating the decision-making process. The use cases driven value chain from Data to Visualization is described in Chapter 6. To close an important gap, a strong emphasis has been made to Climate Information and Communication with Stakeholders in Chapter 7 lining out the importance of consultation work to non-technical users to identify their requirements and optimize the information delivery use-case specific on demand. Some of the value chain elements from raw data to visualization are illustrated by Use cases in Chapter 8. And Lessons Learned (Chapter 9) showcase the pilot’s work and include challenges with the value chain from raw data to climate information. The final chapter, chapter 10Recommendations for future climate resilience pilots describes future work.

3.1.  Analysis Ready Data Cubes — user-friendly sharing of climate data records

Climate Data Record (CDR) is a time series of measurements of sufficient length, consistency, and continuity to determine potential climate variability and change (US National Research Council). These measurements can be obtained through ground based stations or derived from a long time series of satellite data.

Data Cube (Different approaches): Datacubes organize data into a multi-dimensional structure. They contain typically:

• multidimensional arrays of data (Kopp et al., 2019);

• 4-dimensional arrays with dimensions x (longitude or easting), y (latitude or northing), time, and bands sharing the same data properties (Appel and Pebesma, 2019); and

• the term “cube” can be a metaphor to help illustrate a data structure that can in fact be 1- dimensional, 2-dimensional, 3-dimensional, or higher-dimensional. The dimensions may be coordinates or enumerations, e.g., categories (OGC, 2021).

The common (technical) definition of the Data Cube focuses on the data structure aspects exclusively!

Analysis Ready Data (ARD) — are data sets that have been processed to a minimum set of requirements and organized into a form that allows immediate analysis with a minimum of additional user effort and interoperability both through time and with other datasets. ARDs often represent satellite data (CEOS website).

The idea behind the ARD is that data providers, such as EUMETSAT or ESA, are better suited to perform data pre-processing, e.g., atmospheric correction, cloud masking, and re-gridding, than users.

Analysis Ready Data Cubes (ARDCs)
ARDCs are often made available in the form of data cubes which focus on one specific region (e.g., Swiss Data Cube) or thematic application (e.g., EUMETSAT Drought & Vegetation Data Cube (D&V Data Cube)). Data cubes can also be defined by the type of data they include (e.g., Atmospheric Composition Data Cube (ACDC), Earth System Data Cube (ESDC) + Data Analytics Toolkit (Earth System Data Lab)).
A data cube which contains various climate data records can be generally referred to as Climate Data Cube.

Table 1 — Example Climate Data Cubes

Analysis Ready Data Cubes (ARDCs) play an important role in handling large volumes of data (such as satellite-based CDRs). They are often deployed on different spatial scales and consist of datasets dedicated for particular application. This makes them more accessible, easier to use, and less costly for the users.

3.2.  Data cubes to support wildfire risk analysis

To support the pilot activities, Ecere provided, as an in-kind contribution, a deployment of its GNOSIS Map Server implementing several OGC API standards enabling efficient access to data cubes. The API and backend functionality for these data cubes, improved throughout this pilot, also support a Wildland Fire Fuel indicator workflow for the OGC Disaster Pilot taking place until the end of September 2023. As an end goal of that Disaster Pilot, the data cube API should support machine learning predictions for classifying wildland fire fuel vegetation type from Earth Observation imagery. A number of climate datasets and wildland fire danger indices were also made accessible through that same data cube API. Additional machine learning prediction experiments may be performed based on those datasets as well.

The API and datasets were provided in the hope that they would prove useful to other participants and could be part of Technology Integration Experiments (TIEs) for the pilot and other related OGC initiatives. Mainly due to the exploratory nature of this first phase of the pilot, no successful TIE with these resources with other participants were noted during its execution. However, these resources will remain operational and successful TIEs are expected with them as part of the Disaster Pilot, the OGC Testbed 19 Geo Data Cube tasks, and as future phases of the climate resilience pilot.

3.2.1.  Climate resilience data cubes

During the course of the pilot, the following datasets relevant to climate resilience were optimized and deployed at a data cube API demonstration end-point using the GNOSIS Map Server.

Table 2 — Datasets provided through GNOSIS Map Server data cube API

Data collection	Fields	Temporal interval	Temporal resolution	Spatial extent	Spatial resolution	Additional dimension	Source
ESA sentinel-2 Level-2A	B01..B12, B8A, AOT, WVP, SCL	November 2016 to October 2022	5 days	Global (land only)	10 meters	N/A	COGs and STAC catalogs on AWS
CMIP5 projections (wind speed)	Eastward and Northward wind velocity	2016 to 2025	daily	Global	2.5° longitude x 2° latitude	8 pressure levels	Copernicus Climate Data Store
CMIP5 projections (air temperature)	Air temperature	2016 to 2025	daily	Global	2.5° longitude x 2° latitude	8 pressure levels	Copernicus Climate Data Store
CMIP5 projections (geopotential height)	Geopotential height	2016 to 2025	daily	Global	2.5° longitude x 2° latitude	8 pressure levels	Copernicus Climate Data Store
CMIP5 projections on single level	Near-surface specific humidity, Precipitation, Snowfall flux, Sea level pressure, Surface downwelling shortwave radiation, Daily-mean near-surface wind speed, Average, Minimum and Maximum, near-surface air temperature	2016 to 2025	daily	Global	2.5° longitude x 2° latitude	N/A	Copernicus Climate Data Store
ERA5 reanalysis (relative humidity)	Relative humidity	April 1 to 6, 2023	hourly	Global	0.25° longitude x 0.25° latitude	37 pressure levels	Copernicus Climate Data Store
ECMWF CEMS Fire Danger indices	Burning index, Build-up index, Danger risk, Drought code, Duff moisture code, Fire danger severity rating, Energy release component, Fire danger index, Fine fuel moisture code, Forest fire weather index, Ignition component, Initial spread index, Keetch-byram drought index, Spread component	January 2021 to July 2022	daily	Global (except Antarctica)	0.25° longitude x 0.25° latitude	N/A	Copernicus Climate Data Store
Fuel Vegetation Types for Continental United States	Fuel vegetation type	2022 (no time axis)	N/A	Continental U.S.	~20 meters	N/A	landfire.gov

Figure 5 — ESA sentinel-2 Level-2A from COGs and STAC catalogs on AWS

Figure 6 — CMIP5 projections (air temperature) from Copernicus Climate Data Store

Figure 7 — ECMWF CEMS Fire Danger indices from Copernicus Climate Data Store

Figure 8 — Fuel Vegetation Types for Continental United States from landfire.gov

3.2.2.  Overview of supported OGC API standards to access the data

The GNOSIS Map Server implements several published and candidate OGC API standards and is a certified implementation of OGC API — Features as well as OGC API — Processes. This section describes some of these supported standards and illustrates their use with requests for the climate data collections listed above.

3.2.2.1.  OGC API — Common

The OGC API standards form a complementary set of functionality for efficiently accessing data and processing resources, combining together through the OGC API — Common framework. Whereas OGC API — Common — Part 1 standardizes how the API can present a landing page, describe itself, and declare conformance to specific standards, Part 2 provides a consistent mechanism to list and describe collections of geospatial data. The following Common resources are available from the GNOSIS Map Server demonstration end-point:

Table 3 — Common resources that are available from the GNOSIS Map Server

Resource	Common Part	URL
Landing page	Part 1	https://maps.gnosis.earth/ogcapi
OpenAPI description	Part 1	https://maps.gnosis.earth/ogcapi/api
Conformance declaration	Part 1	https://maps.gnosis.earth/ogcapi/conformance
List of collections	Part 2	https://maps.gnosis.earth/ogcapi/collections
Collection description	Part 2	https://maps.gnosis.earth/ogcapi/collections/{collectionId}

In addition to the common resources standardized by Part 1 and Part 2, several API building blocks are consistently re-used across the different OGC API standards. The following table summarizes common query parameters supported by several of the data access APIs:

Table 4 — Common query parameters

Query parameter	Description	APIs
subset	For subsetting (trimming or slicing) on an arbitrary dimension	Coverages, Maps, Tiles (except for spatial dimensions), DGGS (zone query; for data retrieval: except for DGGS dimensions)
bbox	For subsetting on spatial dimensions (Features: spatial intersection)	Coverages, Maps, DGGS (zone query), Features
datetime	For subsetting on temporal dimension (Features: temporal intersection)	Coverages, Maps, Tiles, DGGS (data retrieval: except for temporal DGGS), Features
properties	For selecting specific properties to return (range subsetting); deriving new fields (properties) using CQL2 expression	Coverages, Tiles, DGGS, Features
filter	For filtering using a CQL2 expression	Coverages, Maps, Tiles, DGGS, Features
crs	For selecting an output coordinate reference system	Coverages, Maps, Features
bbox-crs	For specifiying the coordinate reference system of the bbox parameter	Coverages, Maps, Features, DGGS
subset-crs	For specifiying the coordinate reference system of the subset parameter	Coverages, Maps, DGGS
width	For specifying the width of the output (resampling)	Coverages, Maps
height	For specifying the height of the output (resampling)	Coverages, Maps

With Coverages and Maps, a spatial area of interest can be specified using either, e.g., bbox=10,20,30,40 or subset=Lat(20:40),Lon(10:30).

For temporal datasets, a specific time can be requested using, e.g., datetime=2022-03-01 or subset=time("2022-03-01").

For the data cubes with multiple pressure levels, the pressure dimension is defined and can be used with the subset query parameter with all of the data access OGC API standards (Coverages, Tiles, DGGS and Maps), e.g., subset=pressure(500).

3.2.2.2.  OGC API — Coverages

The OGC API — Coverages candidate Standard is a simple API defining fundamental functionality to retrieve access data for arbitrary fields, area, time, and resolution of interest from a data cube.

The main resource to retrieve data using the Coverages API is located at /collections/{collectionId}/coverage for each data collection. This resource supports a number of query parameters defined by optional requirements classes and extensions supported by the GNOSIS Map Server.

Table 5 — Supported query parameters defined by optional requirements classes and extensions supported by the GNOSIS Map Server

Query parameter	Description	Requirements class
subset	For subsetting (trimming or slicing) on an arbitrary dimension	Subsetting
bbox	For subsetting on spatial dimensions	Subsetting
datetime	For subsetting on temporal dimension	Subsetting
scale-factor	For resampling using the same factor for all dimensions (1: no resampling, 2: 2x downsampling)	Scaling (resampling)
scale-axes	For resampling using a specific factor for individual dimensions	Scaling (resampling)
scale-size	For resampling by specifying the expected number of cells for each dimension	Scaling (resampling)
width	For specifying the width of the output (resampling)	Scaling (resampling)
height	For specifying the height of the output (resampling)	Scaling (resampling)
properties	For selecting specific properties to return (range subsetting); deriving new fields using CQL2 expression	Range subsetting; Derived fields extension
filter	For filtering using a CQL2 expression	Range filtering extension
crs	For selecting an output coordinate reference system	CRS extension
bbox-crs	For specifiying the coordinate reference system of the bbox parameter	CRS extension
subset-crs	For specifiying the coordinate reference system of the subset parameter	CRS extension

The Coverages draft currently also specifies a DomainSet JSON object which is linked using the [ogc-rel:coverage-domainset] link relation from the collection description, which may be included either within the collection description itself, or at a dedicated resource (/collections/{collectionId}/coverage/domainset). The schema for this DomainSet object describes the domain of the coverage (the extent and resolution of its dimensions / axes) and follows the Coverages Implementation Schema (CIS) 1.1.1. An example of such a domain set resource can be found at https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:byPressureLevel:windSpeed/coverage/domainset?f=json .

At the time of writing this report discussions are underway to potentially simplify the API by fully describing the domain directly within the collection description resource, using uniform additional dimensions, as well as the grid property, inside the extent property, which can describe both regular as well as irregular grids, removing the need for this extra resource. For example, see the collection description for the CMIP5 single pressure level data and its corresponding CIS domain set resource.

The Coverages draft currently also specifies a RangeType JSON object which is linked using the [ogc-rel:coverage-rangetype] link relation from the collection description, which may be included either within the collection description itself or at a dedicated resource (/collections/{collectionId}/coverage/domainset). The schema for this RangeType object describes the range type of the coverage (the extent and resolution of its dimensions / axes) and follows the Coverages Implementation Schema (CIS) 1.1.1. An example of such a range type resource can be found at https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:byPressureLevel:windSpeed/coverage/rangetype?f=json . It might be possible to also describe the range type in a common way across the different OGC APIs using a JSON schema with semantic annotations, as per the work undertaken for OGC API — Features — Part 5: Schemas.

A Coverage Tiles requirements class is defined in OGC API — Coverages, leveraging the OGC API — Tiles standard while clarifying requirements for coverage tile responses. Examples of coverage tile requests are described below in the OGC API — Tiles section.

At the moment, the GNOSIS Map Server implementation of Coverages is limited to the following 2D (spatial dimensions) output formats:

• GeoTIFF (multiple fields, two-dimensional); and

• PNG (single field, 16-bit output, currently using fixed scale (2.98) and offset (16384) modifiers).

There is a plan to add support for n-dimensional output formats, including netCDF, CIS JSON, and eventually CoverageJSON, as well. For coverages with more than two dimensions, a specific time and/or pressure slice must therefore be selected, currently requiring separate API requests to retrieve a range of time or pressure levels.

Some example of coverage requests:

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/coverage?f=geotiff=tas,tasmax,tasmin,pr,psl=Lat(-90:90),Lon(0:180)=400=2020-05-20 (GeoTIFF coverage with 5 bands for each field)

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/coverage?f=geotiff=pressure(750) (GeoTIFF Coverage)

Figure 9 — Coverage request for CMIP5 maximum daily temperature

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/coverage?f=png=(tasmax-250)*400

3.2.2.3.  OGC API — Maps

The OGC API — Maps candidate Standard defines the ability to retrieve a visual representation of geospatial data. The main resource to retrieve data using the Maps API is located at /collections/{collectionId}/map for each data collection. This resource supports a number of query parameters defined by optional requirements classes and extensions supported by the GNOSIS Map Server.

Table 6 — Supported query parameters defined by optional requirements classes and extensions supported by the GNOSIS Map Server

Query parameter	Description	Requirements class
bbox	For subsetting on spatial dimensions	Spatial Subsetting
bbox-crs	For specifiying the coordinate reference system of the bbox parameter	Spatial Subsetting
subset	For subsetting (trimming or slicing) on an arbitrary dimension	Spatial/Temporal/General Subsetting
subset-crs	For specifiying the coordinate reference system of the subset parameter	Spatial/Temporal/General Subsetting
datetime	For subsetting on temporal dimension	Temporal Subsetting
width	For specifying the width of the output (resampling)	Scaling (resampling)
height	For specifying the height of the output (resampling)	Scaling (resampling)
crs	For selecting an output coordinate reference system	CRS
bgcolor	For specifiying the color of the background	Background
transparent	For specifiying whether the background should be transparent	Background
filter	For filtering using a CQL2 expression	Filtering extension

Some example map requests:

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/map?width=2048=pressure(750)=0x002040

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:byPressureLevel:windSpeed/map?subset=pressure(850)=1024

NOTE:    Proper symbolization for this wind velocity map (above request) would require support for wind barbs. In the meantime, the Eastward and Northward velocities are assigned to the green and blue color channels.

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:byPressureLevel:temperature/map?subset=pressure(850)

Figure 10 — Sentinel-2 map (natural color)

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/map?subset=Lat(-16.259765625:-16.2158203125),Lon(124.4091796875:124.453125)=2022-06-28

Some example map requests for a specific style, in conjunction with OGC API — Styles:

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/styles/precipitation/map?datetime=2022-09-04

Figure 11 — Sentinel-2 map for NDVI style

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/styles/ndvi/map?subset=Lat(-16.259765625:-16.2158203125),Lon(124.4091796875:124.453125)=2022-04-28

Figure 12 — Sentinel-2 map for Scene Classification Map style

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/styles/scl/map?subset=Lat(-16.259765625:-16.2158203125),Lon(124.4091796875:124.453125)=2022-06-28

A Map Tilesets requirements class is defined in OGC API — Maps, leveraging the OGC API — Tiles stand while clarifying requirements for map tile responses. Examples of map tiles requests are described below in the OGC API — Tiles section.

3.2.2.4.  OGC API — Tiles

The OGC API — Tiles Standard defines the ability to retrieve geospatial data as tiles based on the OGC 2D Tile Matrix Set and Tileset Metadata Standard, originally defined as part of the Web Map Tile Service (WMTS) Standard. Unlike WMTS, which focused strictly on pre-rendered or server-side rendered Map tiles, the Tiles API was designed to also enable the use of data tiles such as Coverages Tiles and Vector Tiles which can be styled, rendered, and used for data analytics performed on the client side. Using pre-determined partitioning schemes facilitates caching for both servers and clients, resulting in more responsive dynamic maps.

The following Tiles API resources are defined:

Table 7 — Tiles API resources

Resource	Requirements Class	Description
…​/tiles	Tilesets list	List of available tilesets
…​/tiles/{tileMatrixSetId}	Tileset	Description of tileset and link to 2D Tile Matrix Set definition
…​/tiles/{tileMatrixSetId}/{tileMatrix}/{tileRow}/{tileCol}	Core	Tiles for a given Tile 2D Matrix Set, tile matrix/row/column

The GNOSIS Map Server supports a number of 2D Tile Matrix Sets for all of the collections it hosts, including:

• the GNOSIS Global Grid (EPSG:4326),

• WorldCRS84Quad (EPSG:CRS84 / EPSG:4326),

• WebMercatorQuad (EPSG:3857),

• WorldMercatorWGS84Quad (EPSG:3395),

• ISEA9R (ISEA),

3.2.2.4.1.  Coverage Tiles

The GNOSIS Map Server currently supports the following coverage tile formats:

• GNOSIS Map Tiles (multiple fields, n-dimensional);

• GeoTIFF (multiple fields, two-dimensional); and

• PNG (single field, 16-bit value using fixed scale (2.98) and offset (16384) modifiers).

Support is planned for netCDF, CIS JSON, and eventually CoverageJSON, as well as additional formats.

Example coverage tile queries:

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage/tiles/GNOSISGlobalGrid/3/4/17

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage/tiles/ISEA9Diamonds/4/373/288

To request a different sentinel-2 band than the default RGB (B04, B03, B02) bands:

Figure 13 — Sentinel-2 PNG coverage tile for band 08 (near infra-red)

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage/tiles/GNOSISGlobalGrid/3/4/17?properties=B08=png

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage/tiles/ISEA9Diamonds/4/373/288?properties=B08

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/coverage/tiles/WebMercatorQuad/1/1/0?f=geotiff=2022-09-04 (GeoTIFF coverage tile)

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/coverage/tiles/WorldCRS84Quad/0/0/0?f=geotiff=pressure(750) (GeoTIFF coverage tile)

3.2.2.4.2.  Map Tiles

The GNOSIS Map Server currently supports the following map tile formats:

• PNG (RGBA)

• JPEG

• GeoTIFF

• GNOSIS Map Tiles

Some example of map tiles queries:

Figure 14 — Sentinel-2 Level-2A map tile for GNOSISGlobalGrid level 3, row 4, column 17

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/map/tiles/GNOSISGlobalGrid/3/4/17

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/map/tiles/ISEA9Diamonds/4/373/288

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/map/tiles/WorldCRS84Quad/0/0/0?subset=pressure(750)=0x002040

To get map tiles from a predefined style, in conjunction with OGC API — Styles:

Figure 15 — Sentinel-2 Level-2A map tile using Scene Classification Map style for GNOSISGlobalGrid level 3, row 4, column 17

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/styles/scl/map/tiles/GNOSISGlobalGrid/3/4/17

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/styles/scl/map/tiles/ISEA9Diamonds/4/373/288

Figure 16 — Sentinel-2 Level-2A map tile using NDVI style for GNOSISGlobalGrid level 3, row 4, column 17

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/styles/ndvi/map/tiles/GNOSISGlobalGrid/3/4/17

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/styles/ndvi/map/tiles/ISEA9Diamonds/4/373/288

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/styles/precipitation/map/tiles/WebMercatorQuad/1/1/0?datetime=2022-09-04

3.2.2.5.  OGC Common Query Language (CQL2)

The OGC Common Query Language, abbreviated CQL2, allows the user to define query expressions. Although introduced as a language to specify a boolean predicate for OGC API — Features — Part 3: Filtering, the language is easily extended for additional use cases, such as filtering the range set of a coverage request, or deriving new fields using expressions—​that can return non-boolean values—​including performing coverage band arithmetics, such as calculating vegetation indices.

Support for CQL2 in the filter parameter is implemented in the GNOSIS Map Server for Coverages, Features, Maps, Tiles as well as DGGS. For example, requesting all data from the CMIP5 single pressure level collection where the maximum daily temperature is greater than 300 Kelvins, filter=tasmax>300 (unmatched cells will be replaced by NODATA values).

Support for CQL2 in the properties parameter is currently implemented for Coverages, Tiles and DGGS. For example, the pr precipitation property can be multiplied by a factor of one thousand using properties=pr*1000.

Using a CQL2 expression to filter out the clouds in a map tile:

Figure 17 — Sentinel-2 map tile filtered by Scene Classification Layer to remove clouds (a longer time interval with fewer clouds would be necessary to complete the mosaic)

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/map/tiles/GNOSISGlobalGrid/3/4/17?filter=SCL8 or SCL>10

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/map/tiles/ISEA9Diamonds/4/373/288?filter=SCL8 or SCL>10

Using a CQL2 expression in coverage tile requests to perform band arithmetic computing NDVI:

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage/tiles/GNOSISGlobalGrid/3/4/17?properties=(B08/10000-B04/10000)/(B08/10000+B04/10000)

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage/tiles/ISEA9Diamonds/4/373/288?properties=(B08/10000-B04/10000)/(B08/10000+B04/10000)

Figure 18 — Coverage tile request from sentinel-2 computing NDVI

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/coverage/tiles/GNOSISGlobalGrid/3/4/17?properties=(B08/10000-B04/10000)/(B08/10000+B04/10000)*10000=png

Using a CQL2 expression in a coverage request to multiply the relative humidity and filter resulting values below a threshold (20):

Figure 19 — Coverage request from relative humidity coverage multiplying r by 200 and returning only values where r > 20

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/coverage?f=png=pressure(750),Lat(-90:90),Lon(0:180),time(%222023-04-03%22)=r*200=r%3E20

3.2.2.6.  OGC API — Discrete Global Grid Systems

The OGC API — DGGS candidate Standard allows the retrieval of data and performance of spatial queries based on hierarchical multi-resolution discrete grids covering the entirety of the Earth. There are three main requirement classes for this standard:

• Core (DGGS definition and zone information resource);

• Zone Data Retrieval (What is here?); and

• Zones Query (Where is it?).

The following DGGS API resources are defined:

Table 8 — DGGS API resources

Resource	Requirements Class	Description
…​/dggs	Core	List of available DGGSs
…​/dggs/{dggsId}	Core	Description and link to definition of a specific DGGS
…​/dggs/{dggsId}/zones	Zone Query	For retrieving the list of zones matching a collection and/or query
…​/dggs/{dggsId}/zones/{zoneId}	Core	For retrieving information about a specific zone
…​/dggs/{dggsId}/zones/{zoneId}/data	Data Retrieval	For retrieving data for a specific zone

DGGS API requests imply the use a particular grid, understood by both the client and the server, associated with the {dggsId} of the resource on which the request is performed. Several different discrete global grids have been defined. The GNOSIS Map Server currently supports two discrete global grids:

• the GNOSIS Global Grid, based on the 2D Tile Matrix Set of the same name defined in the EPSG:4326 geographic CRS, axis-aligned with latitude and longitude, and using variable width tile matrices to approach equal area (maximum variation is ~48% up to a very detailed zoom level); and

• the ISEA9R (Icosahedral Snyder Equal Area aperture 9 Rhombus) grid, a dual DGGS of ISEA3H (aperture 3 hexagonal) for its even levels, using rhombuses/diamonds which, compared to hexagons, are much simpler to index and for which it is much easier to encode data in rectilinear formats such as GeoTIFF. The area values of ISEA3H hexagons can be transported as points on the rhombus vertices for those ISEA3H even levels. The ISEA9R grid is also axis-aligned to a CRS defined by rotating and skewing the ISEA projection, also allowing the definition of a 2D Tile Matrix Set for it.

A client will normally opt to use OGC API — DGGS if the client shares an understanding and internal use of the same grid with the server. Although, for axis-aligned DGGS that can be represented as a 2D Tile Matrix Set OGC, API — Tiles can be used to retrieve data for specific zones. The DGGS API enables zone data retrieval for other DGGS which are not axis-aligned or whose geometry makes that impossible (e.g., hexagons). Another important use of the DGGS API is the ability to efficiently retrieve the results of a spatial query (e.g., using CQL2) in the form of a compacted list of zone IDs.

3.2.2.6.1.  Core

The core requirements class defines requirements for listing available DGGS, describing each of them, and providing information for individual zones.

In the GNOSIS Map Server implementation of the zone information resource, since both supported DGGS also correspond to a 2D Tile Matrix Set, the Level, Row, and Column for the equivalent OGC API — Tiles request is displayed on the information page, as can be seen below.

For the DGGS {zoneId}, the level, row, and column are encoded differently in a compact hexadecimal identifier.

Some example zone information requests:

Figure 20 — GNOSIS Map Server information resource for GNOSIS Global Grid zone 5-24-6E

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/dggs/GNOSISGlobalGrid/zones/5-24-6E

Figure 21 — GNOSIS Map Server information resource for ISEA9Diamonds zone A7-0

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/dggs/ISEA9Diamonds/zones/A7-0

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/dggs/ISEA9Diamonds/zones/E7-FAE

3.2.2.6.2.  Zone Data Retrieval: What is here?

The Zone Data Retrieval requirements class allows the retrieval of data for a specific DGGS zone. For axis-aligned DGGSs whose zone geometry can be described by a 2D Tile Matrix Set, such as the GNOSISGlobalGrid, ISEA9R, or rHealPix, this capability is equivalent to Coverage Tiles requests for the corresponding TileMatrixSets. This requirements class supports returning data for zones whose geometries are of an arbitrary shape, e.g., hexagonal or triangular.

The zone data retrieval resource is …​/dggs/{dggsId}/zones/{zoneId}/data, for which the GNOSIS Map Server supports a number of query parameters:

Table 9 — Query parameters supported by the GNOSIS Map Server

Query parameter	Description
filter	For filtering data within the response using a CQL2 expression
properties	For selecting specific properties to return (range subsetting); deriving new fields using CQL2 expression
datetime	For subsetting on temporal dimension
subset	For subsetting (trimming or slicing) on an arbitrary dimension (besides the DGGS dimensions)
subset-crs	For specifiying the coordinate reference system of the subset parameter
zone-depth	For specifying zone depths to return relative to the requested zone (0 corresponding to a single set of values for the zone itself)

Some example of data retrieval queries:

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/dggs/GNOSISGlobalGrid/zones/3-4-11/data

https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/dggs/ISEA9Diamonds/zones/E7-FAE/data

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/dggs/GNOSISGlobalGrid/zones/0-0-3/data?f=geotiff=2023-04-03

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/dggs/GNOSISGlobalGrid/zones/0-0-3/data?f=geotiff=2022-09-04

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/dggs/ISEA9Diamonds/zones/A7-0/data?f=geotiff=2023-04-03

https://maps.gnosis.earth/ogcapi/collections/climate:cmip5:singlePressure/dggs/ISEA9Diamonds/zones/A7-0/data?f=geotiff=2022-09-04

3.2.2.6.3.  Zone Queries: Where is it?

The Zone Query requirements class allows the efficient retrieval of the results of a spatial query in the form of a compact list of zone IDs. The list can be compacted (the default) by replacing children zones by their parents when all children of that parent are part of the result set. The zone query resource is …​/dggs/{dggsId}/zones, for which the GNOSIS Map Server supports a number of query parameters:

Table 10 — Zone query parameters supported by the GNOSIS Map Server

Query parameter	Description
zone-level	For specifying the desired zone hierarchy level for the resulting list of zone IDs
compact-zones	For specifying whether to return a compact list of zones (defaults to true)
filter	For filtering using a CQL2 expression
datetime	For subsetting on temporal dimension
bbox	For subsetting on spatial dimensions
bbox-crs	For specifiying the coordinate reference system of the bbox parameter
subset	For subsetting (trimming or slicing) on an arbitrary dimension
subset-crs	For specifiying the coordinate reference system of the subset parameter

By creating a kind of mask at a specifically requested resolution level, DGGS Zones Query can potentially greatly help parallelization and orchestration of spatial queries combining multiple datasets across multiple services, allowing the performance of early optimizations with lazy evaluations.

NOTE:    There are currently some limitations to the GNOSIS Map Server implementation of the Zones Query requirements class.

Examples of zone queries:

Where is relative the humidity at 850 hPa greater than 80% on April 3rd, 2023? (at the precision level of GNOSIS Global Grid level 6)

(using the default compact-zones=true where children zones are replaced by parent zones if all children zones are included)

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/dggs/GNOSISGlobalGrid/zones?subset=pressure(850)=2023-04-03=r%3E80=6=json (Plain Zone ID list output)

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/dggs/GNOSISGlobalGrid/zones?subset=pressure(850)=2023-04-03=r%3E80=6=uint64 (Binary 64-bit integer Zone IDs)

https://maps.gnosis.earth/ogcapi/collections/climate:era5:relativeHumidity/dggs/GNOSISGlobalGrid/zones?subset=pressure(850)=2023-04-03=r%3E80=6=geotiff (GeoTIFF output)