I. Abstract
The OGC API — Discrete Global Grid Systems — Part 1: Core Standard defines requirements that can be implemented and integrated into a deployed Web API. The DGGS API allows to retrieve geospatial data for a specific area, time and resolution of interest, based on a specific DGGRS. Additionally, the DGGS API defines operations to query the list of DGGRS zones from which data is available and/or matching a specified query. Such queries are expressed by combining HTTP query parameters, including the possibility to express more complex filtering queries using the OGC Common Query Language (CQL2).
Readers are strongly encouraged to first familiarize themselves with the DGGS concepts defined in OGC Abstract Specification Topic 21 laying the foundation for this Standard.
Please note that in the remainder of this document, the Standard will be referred to as the “OGC API – DGGS Standard”, “the DGGS API” or “this Standard”.
II. Keywords
The following are keywords to be used by search engines and document catalogues.
ogcdoc, OGC document, API, openapi, html, ogcapi, DGGS, discrete global grid, ISEA, hexagonal grids
III. Preface
This document defines the OGC API — Discrete Global Grid Systems — Part 1: Core Standard. Suggested additions, changes and comments on this standard are welcome and encouraged. Such suggestions may be submitted as an issue on the OGC API — DGGS GitHub repository.
OGC API Standards define modular API components to spatially enable Web APIs in a consistent way. OGC API Standards use the OpenAPI specification for describing the API components.
The OGC API — Discrete Global Grid Systems defines API components to retrieve data and query zones based on Discrete Global Grid Systems (DGGS) concepts defined in OGC Abstract Specification Topic 21. Additional parts for the OGC API — Discrete Global Grid Systems Standard may be defined in the future to provide additional capabilities.
IV. Security considerations
OGC API — DGGS — Part 1 only defines HTTP GET operations. As such the security considerations are limited to those applicable to a “read only” service. However, implementations of the OGC API — DGGS Standard will have to process resource paths and query parameters in a way that cannot be used by a client to inject malicious queries that makes available unforeseen data or even force the server to perform unwanted or dangerous actions. The following paragraphs enumerate some security considerations.
Due to the flexibility in querying DGGS zones, implementations of the OGC API — DGGS Standard that are not optimized can easily encounter requests that take some time to resolve. If several of these requests are processed simultaneously, the server can become slow or unresponsive. Servers should take advantage of the space partitioning structures of the implemented Discrete Global Grid Reference Systems (DGGRSs) that guarantee a deterministic maximum amount of data to process, ensuring that maximum refinement level is used for regions covering a larger area, and refusing requests which would otherwise be problematic for the server. Servers should also set and apply reasonable limits (e.g., maximum number of zones to return, etc.) to prevent Denial of Service attacks.
Some deployments of the OGC API — DGGS Standard may assign different roles to different users that may result in accessing different collections or geographical areas for which data can be retrieved or zones can be queried. The access control can be described in the OpenAPI definition as discussed in the OGC API — Common Standard (https://docs.ogc.org/is/19-072/19-072.html#rc_oas30-security). Servers should take care that all resources in all representations and ways they can be requested (e.g., adding query parameters) are managed consistently.
Another security consideration is that DGGS data or DGGS zone lists returned by a DGGS API endpoint may be positionally incorrect and potentially guide users to wrong locations. One possible way this situation could happen is the manipulation by a malicious actor of a projection library installed on a server deployment.
Using HTTPS queries is preferred to using HTTP. The obvious reason is the DGGS response returned by the DGGS API endpoint should be only accessible to the requesting user. Another reason is related to the public accessibility of the request itself. Request to a DGGS API endpoint reveal geographical extents that might be associated with private or sensitive information. For instance, users commonly visit “home” or “work” or “target places” (such as holiday destinations or churches). These requests can be used to predict personal or private activities.
V. Submitting Organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
- Pangaea Innovations Pty. Ltd.
- Ecere Corporation
- Landcare Research New Zealand
- Peking University Collaborative Innovation Center for Geospatial Big Data
- European Commission Joint Research Centre
- Natural Resources Canada
- University of Tartu
- European Space Agency
- Open Geospatial Foundation
- University of Calgary
- GeoInsight AG
VI. Submitters
All questions regarding this submission should be directed to the editors or the submitters:
| Name | Affiliation |
| Matthew Brian John Purss (editor) | Pangaea Innovations Pty. Ltd. |
| Jérôme Jacovella-St-Louis (editor) | Ecere Corporation |
| Robert Gibb | Landcare Research New Zealand |
| Fuhu Ren / 任伏虎 | Peking University Collaborative Innovation Center for Geospatial Big Data |
| Peter Strobl | European Commission Joint Research Centre |
| Ryan Ahola | Natural Resources Canada |
| Alexander Kmoch | University of Tartu |
| Ferran Gascon | European Space Agency |
| Luís Moreira de Sousa | Open Source Geospatial Foundation |
| Perry Peterson | University of Calgary |
| Michael Jendryke | GeoInsight AG |
VII. Acknowledgements
This OGC Standard builds on a vast amount of research on Discrete Global Grid Systems spanning multiple decades, in particular from John P. Snyder (Snyder1992), Michael F. Goodchild (Goodchild1992), Kevin Sahr (Sahr2003), Robert Gibb (Gibb2016), Perry R. Peterson (Peterson2019), and several others.
Initial implementations of a previous iteration of a draft DGGS API and an Engineering Report produced thanks to funding from OGC Testbed 16 (OGC 20-039r2) informed the development of this Standard. Note that the API defined by this Standard differs significantly from that earlier iteration, with a greater emphasis on client requests asking a Web API implementation questions of the type “What is here?” and “Where is it”? (Peterson2019). This Standard assumes a shared understanding of a particular Discrete Global Grid Reference System between the client and the server, which could be implemented by a local DGGRS software library, avoiding the need to define HTTP resources to query the conceptual grid hierarchy structure. The definition of an API in the traditional software development sense for such DGGRS libraries is beyond the scope of this Standard.
Key work leading to the creation of this OGC Standard was undertaken as part of GeoConnections 2020-2021 and 2025-2027 projects GNS20-21IFP02 (Modular OGC API Workflows) (OGC 21-033) and GNS25-27IFP2 (Advancing and Implementing OGC Standards for GeoDataCubes, DGGSs, Data Stores for Digital Twins and Cartographic Symbology). Financial support provided by GeoConnections, a national collaborative initiative led by Natural Resources Canada. GeoConnections supports the modernization of the Canadian Geospatial Data Infrastructure (CGDI). The CGDI is the collection of geospatial data, standards, policies, applications, and governance that facilitate its access, use, integration, and preservation. Research activity and Technology Integration Experiments performed as part of the OGC Federated Marine SDI — Phase 3 (OGC 23-010) pilot project also played a key role in refining the design of the API and the Discrete Global Grid Reference Systems based on the ISEA projection included in Annex B.
1. Scope
This OGC API — DGGS Standard specifies a Web API that enables the direct retrieval of geospatial data for a specified area, time and resolution of interest, based on a specific DGGRS. Additionally, the DGGS API defines operations to query the list of DGGRS Zones from which data is available and/or matching a particular query. Such queries are expressed by combining HTTP query parameters, including the possibility to express more complex filtering queries using the OGC Common Query Language (CQL2).
This Standard also specifies several encodings for retrieving both DGGS data and lists of zones, including JSON encodings suitable for data quantized to DGGRS zones of arbitrary geometries as well as widely adopted geospatial data formats. Compact binary representations for zone data as well as for lists of zones are proposed as well.
An informative annex presents a JSON schema for describing a (DGGRS, as well as examples of such DGGRS definitions which can be implemented in connection with this standard.
2. Conformance
The one Standardization Target for this Standard is Web APIs.
OGC API — Common provides a common foundation for OGC API Standards. Some conformance classes of this standard have a dependency on, or are designed to be easily integrated with, conformance classes defined in OGC API — Common — Part 1 and/or Part 2, as well as within a Web API conforming to additional OGC API Standards.
This Standard identifies twenty-five Conformance Classes. Each Conformance Class has an associated Requirements Class. The Requirements Classes define the functional requirements which will be tested through the associated Conformance Class. Only the Core requirements class is mandatory, all others are optional. However, a Web API with practical use needs to implement either the Data Retrieval and/or the Zone Query requirements class.
Conformance with this Standard shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site.
To conform to this OGC API — DGGS Standard, a software implementation shall implement at minimum the “Core” requirements class, as well as either the “Data Retrieval” and/or the “Zone Query” requirements class.
All requirements-classes and conformance-classes described in this document are owned by the standard(s) identified.
The Requirements Classes for OGC API — Discrete Global Grid Systems are:
2.1. Requirements classes defining resources
In addition to the Core requirements class defining the ../dggs, ../dggs/{dggrsId} and ../dggs/{dggrsId}/zones/{zoneId} resources, either the Zone Data retrieval (../dggs/{dggrsId}/zones/{zoneId}/data) or Zone Query requirements classes (../dggs/{dggrsId}/zones with support for query parameters such as zone-level=, parent-zone=, compact-zones=, bbox=, bbox-crs, datetime=, subset= and subset-crs=) need to be implemented for a DGGS API implementation to have practical use.
2.2. Requirements classes for integration within the OGC API framework
These requirements classes define DGGS resources attached to the root of the API (/dggs) and collections (/collections/{collectionId}/dggs) origin resources defined by the OGC API — Common framework.
The Operation IDs Requirements Class defines requirements for using specific operation IDs in API definitions, which can be combined with requirements classes for specific API definition, such as the OpenAPI 3.0 requirements class of OGC API — Common — Part 1: Core, facilitating the identification of DGGS resources.
2.3. Requirements classes defining query parameters
Three requirements classes add support for the subset, properties, exclude-properties, zone-depth and filter query parameters to zone data resources:
A requirements class adds support for the filter parameter for zone query resources:
2.4. Requirements classes defining resource representations
2.4.1. Zone data encodings
The Data Encoding Requirements Classes address support for formats commonly used for encoding geospatial data, as well as encodings based on JSON and UBJSON using a schema specifically designed for zone data referenced to a particular DGGRS. DGGS-(UB)JSON allows encoding one or more depths of DGGS-quantized raster data, including optional support for multiple fields (properties) and additional dimensions beyond those of the DGGS, whereas DGGS-(UB)JSON-FG encode vector features and geometry based on OGC Features & Geometry JSON using sub-zone order indices as coordinates at an arbitrary relative depth / precision.
2.4.2. Zone list encodings
The Zone List Encoding Requirements Classes address support for formats efficiently and/or intuitively encoding a list of DGGS zone identifiers, in addition to the simple JSON encoding.
Implementations supporting GeoJSON for either zone data or zone lists are strongly encouraged to also support GeoJSON extensions defined by the Features & Geometry JSON (JSON-FG) Standard. Conformance to this Standard can be indicated in the Web API deployment’s conformance declaration using its associated conformance class URIs, such as http://www.opengis.net/spec/json-fg-1/0.2/conf/core.
2.5. Summary of conformance URIs
Table 1 — Conformance class URIs
3. Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
Robert Gibb: OGC 20-040r3, Topic 21 — Discrete Global Grid Systems — Part 1 Core Reference system and Operations and Equal Area Earth Reference System. Open Geospatial Consortium (2021). http://www.opengis.net/doc/AS/dggs/2.0.
T. Bray (ed.): IETF RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format. RFC Publisher (2017). https://www.rfc-editor.org/info/rfc8259.
Charles Heazel: OGC 19-072, OGC API — Common — Part 1: Core. Open Geospatial Consortium (2023). http://www.opengis.net/doc/is/ogcapi-common-1/1.0.0.
Charles Heazel, Joan Masó, Jérôme Jacovella-St-Louis: OGC API — Common — Part 2: Geospatial Data (Draft). OGC 20-024, Open Geospatial Consortium, https://docs.ogc.org/DRAFTS/20-024.html
Open API Initiative: OpenAPI Specification 3.0.3, https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.3.md
Ben Domenico: OGC 10-090r3, OGC Network Common Data Form (NetCDF) Core Encoding Standard version 1.0. Open Geospatial Consortium (2011) https://portal.ogc.org/files/?artifact_id=43732
Panagiotis (Peter) A. Vretanos, Clemens Portele: OGC 21-065r2, Common Query Language (CQL2). Open Geospatial Consortium (2024). http://www.opengis.net/doc/IS/cql2/1.0.
H. Butler, M. Daly, A. Doyle, S. Gillies, S. Hagen, T. Schaub: IETF RFC 7946, The GeoJSON Format. RFC Publisher (2016). https://www.rfc-editor.org/info/rfc7946.
OGC Features & Geometry JSON (Draft), https://docs.ogc.org/DRAFTS/21-045r1.html
Adobe Developers Association: TIFF Specification Revision 6.0. (1992) https://www.itu.int/itudoc/itu-t/com16/tiff-fx/docs/tiff6.pdf
Emmanuel Devys, Ted Habermann, Chuck Heazel, Roger Lott, Even Rouault: OGC 19-008r4, OGC GeoTIFF Standard. Open Geospatial Consortium (2019). http://www.opengis.net/doc/IS/GeoTIFF/1.1.0.
ISO/IEC: ISO/IEC 18181-1, Information technology — JPEG XL image coding system — Part 1: Core coding system. International Organization for Standardization, International Electrotechnical Commission, Geneva https://www.iso.org/standard/85066.html.
ISO/IEC: ISO/IEC 18181-2, Information technology — JPEG XL image coding system — Part 2: File format. International Organization for Standardization, International Electrotechnical Commission, Geneva https://www.iso.org/standard/85253.html.
ISO/IEC: ISO/IEC 15948, Information technology — Computer graphics and image processing — Portable Network Graphics (PNG): Functional specification. International Organization for Standardization, International Electrotechnical Commission, Geneva https://www.iso.org/standard/29581.html.
Chris Little, Jon Blower, Maik Riechert: OGC 21-069r2, OGC CoverageJSON Community Standard. Open Geospatial Consortium (2023). http://www.opengis.net/doc/CS/covjson/1.0.
ISO/IEC: ISO/IEC 21320-1, Information technology — Document Container File — Part 1: Core. International Organization for Standardization, International Electrotechnical Commission, Geneva https://www.iso.org/standard/60101.html.
Zarr Developers: OGC 21-050r1, Zarr Storage Specification 2.0 Community Standard. Open Geospatial Consortium (2022). http://www.opengis.net/doc/CS/zarr/2.0.
Peter Baumann: OGC 21-060r2, Topic 6.3 — Schema for Coverage Geometry and Functions – Part 3: Processing Fundamentals. Open Geospatial Consortium (2024). http://www.opengis.net/doc/AS/Topic-6.3/1.0.
4. Terms and definitions
This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.
This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.
For the purposes of this document, the following additional terms and definitions apply.
immediate descendant of a parent zone
Note 1 to entry: adapted from child cell in OGC Abstract Specification Topic 21
[SOURCE: OGC 20-040r3]
set of zones at the same refinement level, that uniquely and completely cover a globe
Note 1 to entry: Adapted to use zones rather than cells to avoid potential confusion with the similar concept of grid cells in a coverage. As noted in OGC Abstract Specification Topic 21, “While the terms cell and zone are often used interchangeably, strictly zone is the preferred term.”.
[SOURCE: OGC 20-040r3]
series of discrete global grids organized in a hierarchy of successive levels of zone refinement, using a specific set of parameters fully establishing the geometry of all zones
Note 1 to entry: Example of parameters part of the DGGH definition include the underlying Earth model ellipsoid, and the orientation of a base polyhedron.
Note 2 to entry: This definition corresponds to the term “hierarchy” (4.26) in OGC Abstract Specification Topic 21, and refers strictly to a mathematical structure, excluding the concept of zonal identifiers, which are introduced as part of a discrete global grid reference system, and excluding notions of software functionality or interoperability implied by a DGGS.
Note 3 to entry: In some DGGS literature, the term DGGS refers to this DGGH meaning, where the word system in “system of discrete global grids” is used in the sense of a “series” of grids (e.g., “A Discrete Global Grid System (DGGS) is a series of discrete global grids” [Sahr2003]), as opposed to a software or data integration / processing system.
Note 4 to entry: The ISEA3H (Icosahedral Snyder Equal-Area Aperture 3 Hexagonal) Discrete Global Grid Hierarchy, using an ISEA projection with a particular icosahedron orientation mapping the underlying WGS84 ellipsoid Earth model to an authalic sphere, irrespective of a particular indexing scheme or sub-zone ordering, is an example of a DGGH.
[SOURCE: OGC 20-040r3]
integrated system comprised of a specific discrete global grid hierarchy, spatiotemporal referencing by zone identifiers and deterministic sub-zone ordering
Note 1 to entry: the term DGGRS did not appear in the terms and definitions of version 2.0.0 of OGC Abstract Specification Topic 21, but is defined in Section 8 as the DGG_ReferenceSystem interface.
Note 2 to entry: Annex B provides an informative schema for defining a DGGRS with accompanying examples of specific DGGRSs.
Note 3 to entry: this standard introduces the concept of sub-zone ordering, which is not part of the DGG_ReferenceSystem interface defined in topic 21, for the purpose of compact storage and transmission of data quantized to a particular DGGRS.
[SOURCE: OGC 20-040r3]
integrated system comprising a hierarchy of discrete global grids, spatiotemporal referencing by zonal identifiers and functions for quantization, zonal query, and interoperability
Note 1 to entry: In some DGGS literature, the term DGGS is sometimes used with the meaning of a discrete global grid hierarchy.
Note 2 to entry: An implementation of the OGC API — DGGS Standard would be considered a DGGS.
[SOURCE: OGC 20-040r3]
region of space-time enclosing a celestial body
[SOURCE: OGC 20-040r3]
zone in a coarser refinement level of a discrete global grid with immediate descendants
Note 1 to entry: adapted from parent cell in OGC Abstract Specification Topic 21
Note 2 to entry: Adapted to say coarser rather than higher, where coarser refers to a zone covering a larger area of space-time.
[SOURCE: OGC 20-040r3]
numerical order of a discrete global grid in the tessellation sequence
Note 1 to entry: The discrete global grid with the least number of zones has a refinement level of 0.
[SOURCE: OGC 20-040r3]
the number of refinement levels separating a finer discrete global grid from a coarser discrete global grid in a discrete global grid hierarchy
extracting a hyperplane of data along a particular dimension, resulting in a dataset of reduced dimensionality
[SOURCE: OGC 21-060r2]
zone at a greater refinement level than a parent zone whose geometry is at least partially contained within the geometry of the parent zone
Note 1 to entry: At a relative depth of 1, the sub-zones of the parent zone are its immediate children.
Note 2 to entry: In some DGGHs, the children of the children of a parent zone (relative depth of 2) are not all sub-zones of that parent zone.
Note 3 to entry: A discrete global grid reference system defines a deterministic order for sub-zones
extracting a subset of data between a lower and upper bound along one or more dimensions, preserving dimensionality
[SOURCE: OGC 21-060r2]
An Application Programming Interface (API) using an architectural style that is founded on the technologies of the Web
Note 1 to entry: See Best Practice 24: Use Web Standards as the foundation of APIs (W3C Data on the Web Best Practices) for more detail.
[SOURCE: OGC 19-072]
spatiotemporal reference in the form of a label or code that uniquely identifies a zone
Note 1 to entry: synonym of “zonal identifier” and “zone ID”.
Note 2 to entry: This Standard and the DGGRS definitions described in Annex B require textual identifiers (which may or may not be comprised of only digit characters), while optionally supporting 64-bit integer identifiers for the purpose of compact transmission and internal representation.
[SOURCE: OGC 20-040r3]
reference system establishing a specific association of zone identifiers to zones for one or more discrete global grid hierarchy
Note 1 to entry: synonym of “zonal identifier reference system” and “zone indexing scheme”
particular region of space-time
[SOURCE: OGC 20-040r3]
5. Conventions
This section provides details of conventions used in this document.
5.1. Identifiers
The normative provisions in this standard are denoted by the URI https://www.opengis.net/spec/ogcapi-dggs-1/1.0.
All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.
5.2. Link relations
To express relationships between resources, RFC 8288 (Web Linking) is used.
Note that the CURIE based on the pattern [ogc-rel:<relation>] is also considered equivalent. For example, [ogc-rel:dggrs-definition] corresponds to https://www.opengis.net/def/rel/ogc/1.0/dggrs-definition.
The following IANA link relation types are used in this document.
alternate: Refers to a substitute for this context.
self: Conveys an identifier for the link’s context.
service-desc: Identifies service description for the context that is primarily intended for consumption by machines (Web API definitions are considered service descriptions).
service-doc: Identifies service documentation for the context that is primarily intended for human consumption.
The following link relation types which were previously defined for other OGC API standards are applicable:
https://www.opengis.net/def/rel/ogc/1.0/dataset: The target IRI points to a resource representing the dataset (e.g., the root of an OGC Web API).
https://www.opengis.net/def/rel/ogc/1.0/geodata: The target IRI points to a resource representing a collection of geospatial data.
In addition, the following link relation types are used for which no applicable registered link relation type could be identified:
https://www.opengis.net/def/rel/ogc/1.0/dggrs: The target IRI points to the description, which includes a link to the definition as well as deployment-specific elements, of the Discrete Global Grid Reference System related to the link’s context.
https://www.opengis.net/def/rel/ogc/1.0/dggrs-list: The target IRI points to the descriptive list of the Discrete Global Grid Reference Systems available for the resource of the link’s context.
https://www.opengis.net/def/rel/ogc/1.0/dggrs-definition: The target IRI points to the definition of the Discrete Global Grid Reference System using a well-defined schema (see Annex B), for example as available from an authoritative DGGRS registry.
https://www.opengis.net/def/rel/ogc/1.0/dggrs-zone-info: The target IRI points to information about a particular zone of a Discrete Global Grid Reference System, such as its geometry, area/volume, and any relevant links (e.g., to retrieve data from the zone).
https://www.opengis.net/def/rel/ogc/1.0/dggrs-zone-data: The target IRI points to data pertaining to a particular zone of a Discrete Global Grid Reference System. This link relation is typically used with a link template where a zone identifier can be substituted.
https://www.opengis.net/def/rel/ogc/1.0/dggrs-zone-query: The target IRI points to a zone listing resource allowing to perform queries for a particular Discrete Global Grid Reference System.
https://www.opengis.net/def/rel/ogc/1.0/dggrs-zone-parent: The target IRI points to the information resource of a zone which is a parent of the link’s context zone.
https://www.opengis.net/def/rel/ogc/1.0/dggrs-zone-child: The target IRI points to the information resource of a zone which is an immediate child of the link’s context zone.
https://www.opengis.net/def/rel/ogc/1.0/dggrs-zone-neighbor: The target IRI points to the information resource of a zone which is a neighbor of the link’s context zone.
Each resource representation includes an array of links. Implementations are free to add additional links for all resources provided by the Web API implementing OGC API — DGGS requirement(s).
Used in combination with OGC API — Common — Part 1: Core, other link relation types will be used, including:
https://www.opengis.net/def/rel/ogc/1.0/conformance: Refers to a resource that identifies the specifications that the link’s context conforms to.
Used in combination with OGC API — Common — Part 2: Geospatial Data, other link relation types will be used, including:
https://www.opengis.net/def/rel/ogc/1.0/data: Refers to the list of collections available for a dataset.
5.3. Use of HTTPS
For simplicity, the OGC API — DGGS Standard only refers to the HTTP protocol. This is not meant to exclude the use of HTTPS and simply is a shorthand notation for “HTTP or HTTPS.” Following the recent push towards enhancing web security, public facing web servers are expected to use HTTPS rather than HTTP. In the context of the OGC API — DGGS Standard, use of HTTPS provides a layer of security to prevent leaking of information related to users requesting DGGS-structured data or zones list for a particular geographical area, which may be private or sensitive in nature (for example, their own location, or the location of endangered species).
6. Overview
A conforming implementation of OGC API — DGGS supports either or both the Zone Data Retrieval requirements class answering questions of the type “What is here?”, and/or the Zone Query requirements class answering questions of the type “Where is it?”. The resource paths defined by these two requirements classes are tied to information resources defined in the Core requirements class that the implementation also needs to support.
Both of these types of request are always made in the context of a specific DGGRS. Nine examples of DGGRSs which can be used with this DGGS API are presented in Annex B. An implementation of OGC API — DGGS may support one or more DGGRS. Requests using the native DGGRS of the data would normally provide better performance. Because the use of any DGGRS implies the concepts of hierarchical refinement levels and global coverage, having the data stored in any DGGRS should still be practical to support queries using any other DGGRS supported by the implementation with sub-optimal but acceptable performance.
IMPORTANT
This DGGS API is intended primarily for client / server exchanges where both parties are familiar and can efficiently deal with the same DGGRS. Use cases where the client itself also acts as a server as part of data integration workflows are particularly relevant, where the combination of advanced spatial queries with the ability to request data for specific zones of interest can potentially greatly accelerate analytic processing through parallel distributed processing and lazy evaluation.
As a fallback, a client without native support for a particular DGGRS can still retrieve and interpret data from a server implementing support for both zone queries and data retrieval by performing a two-steps operation. First, the client can perform a zone query for an area of interest using the bbox query parameter. Then, the client can request data for the zones returned by this query in a georeferenced encoding which it understands and which is not tightly coupled with the DGGRS (excluding e.g., the DGGS-JSON encoding), such as GeoJSON or GeoTIFF. However, for such use cases, OGC API — DGGS does not present significant advantages over other OGC API data access mechanisms such as OGC API — Coverages, OGC API — Features or OGC API — Tiles.
An implementation of OGC API — DGGS may also support other OGC API access mechanisms for the same data collection for this purpose, while still leveraging the advantages of Discrete Global Grid Systems ‘under the hood’ to respond effectively and in a scalable manner to requests for these other APIs.
Although this Standard defines a number of possible encodings for retrieving Zone Data and encodings for querying zone lists, no particular encoding of Zone Data is mandated by this DGGS API, whereas only the simple JSON representation of Zone Query responses (which consists of an array of textual zone identifiers) is required.
Servers may support additional representations of zone lists beyond JSON, such as a more compact binary 64-bit integers encoding, a GeoJSON representation including zone geometry or an HTML representation for exploring datasets in a browser through the DGGS API. Note that regardless of encoding, zone query responses can also be compressed for additional bandwidth efficiency if the client and server negotiate a content encoding e.g., using Content-Encoding: gzip.
CAUTION
The transfer of zone geometry in zone queries is not an efficient implementation use of the DGGS API for practical analytics purposes. This is because clients should already have built-in knowledge of the selected DGGRS in their local software libraries and can efficiently infer the geometry of a zone from its zone ID alone as needed. In many use cases, the geometry may not be needed at all.
The ability to retrieve zone lists in a geospatial data format such as GeoJSON or GeoTIFF which can readily be visualized in GIS tools is useful for educational, demonstration, and debugging purposes. For example, this functionality can be used to generate grids, such as those seen in Annex B (a crs parameter to request an ISEA planar projection was used in that case to override the default GeoJSON CRS84), as well as the zone visualizations seen in the examples in Annex C.
Implementers may wish to start by reading the Annex C: Examples, which presents use cases alongside example requests and responses, and refer to the requirements as they implement or review the associated functionality.
Readers are also encouraged to refer as needed to OGC Abstract Specification Topic 21, which describes the conceptual foundation for this Standard.
6.1. API Definition
An example OpenAPI 3.0 definition for OGC API — DGGS is provided, defined as individual components which can be assembled with the swagger-cli tool after customizing the API definition for a particular implementation or deployment.
Developers may prefer to first read the documentation for OGC API — DGGS generated from the example OpenAPI definition, which can be visualized with SwaggerUI or ReDocly.
6.2. Resource paths, responses and parameters
The following table summarizes the resources, responses, path parameters and query parameters defined by this API, as well as in which requirements class they are defined. The table links to the relevant API definition components for the responses, parameters and schemas associated with each resource path defined by the API. Links to relevant examples in Annex C are also included.
Table 2 — Summary of DGGS API resource paths, responses and parameters, with links to relevant examples in Annex C
| Resource path | Response | Parameters |
|---|---|---|
| Defined in requirements class Root DGGS (integration with OGC API — Common — Part 1: Core): | ||
| / | Landing Page Response (OpenAPI) / Schema | |
| /dggs… | DGGS Resources (defined in Core, as well as Zone Data Retrieval and/or Zone Query) for the API deployment and/or dataset as a whole | |
| Defined in requirements class Collection DGGS (integration with OGC API — Common — Part 2: Geospatial Data): | ||
| /collections | Collections List Response (OpenAPI) / Schema | Query parameters for discovery within a large number of collections to be defined in a proposed OGC API — Common part (optional for implementation to support): Searchable Collections: limit, bbox, datetime, q, query, below-sd Hierarchical Collections: parent, descendants Filtering Collections with CQL2: filter Sortable Collections: sortby |
| /collections/{collectionId} (see Examples C.1) | Collection Description Response (OpenAPI) / Schema | {collectionId} path parameter (OpenAPI) |
| /collections/{collectionId}/dggs… | DGGS Resources (defined in Core, as well as Zone Data Retrieval and/or Zone Query) for a collection | |
| /collections/{collectionId}/schema (if implementing Data subsetting) | Logical schema for the data returned for this collection (JSON Schema) to be defined in proposed OGC API — Common part, based on OGC API — Features — Part 5: Schemas | |
| /collections/{collectionId}/queryables (if implementing Filtering Zone Queries with CQL2 or Filtering Zone Data with CQL2) | Schema for the queryables that can be used in CQL2 queries for this collection (JSON Schema) as defined in OGC API — Features — Part 3: Filtering | |
| Defined in requirements class Core: | ||
| /dggrs/{dggrsId}, /dggs/{dggrsId}/definition (example paths — could also exist on an authoritative DGGRS register) (see Annex B) | DGGRS Definition Schema | |
| …/dggs (see Examples C.2) | DGGRS List Response (OpenAPI) | |
| …/dggs/{dggrsId} (see Examples C.3) | DGGRS Description Response (OpenAPI) / Schema | {dggrsId} path parameter (OpenAPI) |
| …/dggs/{dggrsId}/zones/{zoneId} (see Examples C.4) | Zone Information Response (OpenAPI) / Schema | {zoneId} path parameter (OpenAPI) |
| Defined in requirements class Zone Query: | ||
| …/dggs/{dggrsId}/zones (see Examples C.5 and Examples C.6) | Zone Query Response (OpenAPI) (defines a mandatory JSON zone list encoding) | Required query parameters: compact-zones (see Examples C.5 and Examples C.6) zone-level (see Examples C.5.1) subset (see Examples C.5.2) subset-crs bbox (see Examples C.5.2) bbox-crs datetime (see Examples C.5.2) parent-zone (see Examples C.5.4) Recommended query parameter (optional for server to support): limit (clients should rely on hierarchical paging with parent-zone and zone-level instead) |
| Optional requirement classes complementing Zone Query | ||
| Some additional possible encodings defined in the following requirements classes: For practical efficient use in DGGS clients / distributed DGGS workflows: 64-bit Binary Zone List For allowing users to explore DGGS zones / data in a hierarchical manner in the browser: HTML Zone List For easily visualizing zone query responses in traditional GIS software: GeoJSON Zone List (GeoJSON or JSON-FG) GeoTIFF Zone List (GeoTIFF, for DGGRSs with axis-aligned rectangular zones) | Required by Filtering Zone Queries with CQL2: filter (CQL2 expression) (see Examples C.7) Recommended by GeoJSON Zone List (optional for server to support): profile geometry | |
| Defined in requirements class Zone Data Retrieval: | ||
| …/dggs/{dggrsId}/zones/{zoneId}/data (see Examples C.8 and Examples C.10) | Zone Data Response (OpenAPI) Encoding negotiated with HTTP Accept: request header | Recommended query parameters (optional for server to support): crs |
| Optional requirement classes complementing Zone Data Retrieval | ||
| Some possible encodings defined in the following requirements classes: For DGGS-quantized raster data: DGGS-JSON Data (DGGS-JSON Schema) DGGS-UBJSON Data (DGGS-JSON encoded as UBJSON) For raster data either DGGS-quantized or using traditional coordinate reference system (based on profile query parameter): netCDF Data (OGC netCDF: 3.0 / classic or 4.0 / HDF5) Zarr Data (zipped OGC Zarr 2.0 and/or GeoZarr) CoverageJSON Data (CoverageJSON) For DGGS-quantized vector data: DGGS-JSON-FG Data (JSON-FG with dggsPlace) DGGS-UBJSON-FG Data (DGGS-JSON-FG encoded as UBJSON) For 2D raster data (interoperable with non-DGGS clients): GeoTIFF Data (GeoTIFF) JPEG XL Data (JPEG XL) PNG Data (PNG) For vector data using traditional coordinate reference system (interoperable with non-DGGS clients): GeoJSON Data (GeoJSON or JSON-FG) | Required by Data custom depths: zone-depth (see Examples C.9) Required by Data subsetting: datetime (see Examples C.10.1) subset (see Examples C.10.2) properties (see Examples C.10.3) exclude-properties Required by Filtering Zone Data with CQL2: filter (CQL2 expression) (see Examples C.10.4) Recommended by DGGS-JSON-FG Data, DGGS-UBJSON-FG Data, GeoJSON Data (optional for server to support): geometry (see Examples C.8.1.3) Recommended by DGGS-JSON-FG Data, DGGS-UBJSON-FG Data, GeoJSON Data, netCDF Data, Zarr Data, CoverageJSON Data (optional for server to support): profile (see Examples C.8.1.4) Recommended by PNG Data (optional for server to support): values-offset values-scale | |
7. Requirements Class “Core”
7.1. Overview
An implementation of the DGGS API “Core” Requirements Class enables a client to list available DGGRSs for a given resource, retrieve additional information about a particular DGGRS, and retrieve information about a particular DGGRS zone.
The “Core” Requirements Class is the only mandatory Requirements Class. However, an implementation with practical use is expected to additionally implement either the “Zone Data Retrieval” Requirements Class, so that a client can ask a question of the type “What is here?” and/or the “Zone Query” Requirements Class, so that a client can ask a question of the type “Where is it?”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/core |
|---|---|
| Target type | Web API |
| Conformance class | Conformance class A.1: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/core |
| Normative statements | Requirement 1: /req/core/dggrs-list Requirement 2: /req/core/dggrs-description Requirement 3: /req/core/zone-info |
7.2. Listing available DGGRSs (…/dggs)
| Identifier | /req/core/dggrs-list |
|---|---|
| Included in | Requirements class 1: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/core |
| Statement | For retrieving the list of available discrete global grid reference systems: |
| A | The Implementation SHALL support an HTTP GET operation at a resource path ending with …/dggs. |
| B | The Implementation SHALL support a JSON representation of this …/dggs resource. |
| C | The …/dggs resource SHALL include a dggrs array property listing all DGGRSs supported by the Implementation. |
| D | Each element of the dggrs array SHALL include a summary description (a subset of the information available in the individual resources describing each DGGRS as per the next requirement below), including at minimum the id, title, uri (if applicable), and links. |
| E | The links property within each DGGRS element SHALL include at minimum a link to the discrete global grid reference system using the self link relation type, as well as a link to the discrete global grid reference system definition using the [ogc-rel:dggrs-definition] relation type. |
| F | The link relation type to use for linking from a particular resource of origin (such as a collection at /collections/{collectionId}, or landing page) to the list of available DGGRSs for that resource (for example at /collections/{collectionId}/dggs or /dggs) SHALL be [ogc-rel:dggrs-list]. |
NOTE: An optional array of links may also be present at the top-level of the DGGRS list resource, for example to link back to the parent resource such as the data collection using the [ogc-rel:geodata] link relation.
See also Examples C.2.
7.3. Discrete Global Grid Reference System (DGGRS) description (…/dggs/{dggrsId})
| Identifier | /req/core/dggrs-description |
|---|---|
| Included in | Requirements class 1: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/core |
| Statement | For retrieving the description of a particular available discrete global grid reference system: |
| A | The Implementation SHALL support an HTTP GET operation at a resource path ending with …/dggs/{dggrsId}. |
| B | The Implementation SHALL support a JSON representation of this …/dggs/{dggrsId} resource. |
| C | The …/dggs/{dggrsId} resource SHALL include an id property consistent with the {dggrsId} resource path parameter. |
| D | The …/dggs/{dggrsId} resource SHALL include a link to the resource itself using the self link relation type. |
| E | The …/dggs/{dggrsId} resource SHALL include a link to a definition of the discrete global grid reference system (describing both the discrete global grid as well as the particular indexing scheme to identify zones by identifiers), using the link relation type [ogc-rel:dggrs-definition]. The schema for that definition is likely to evolve in order to support describing a growing number of classes of DGGHs. A first version of this schema is available in Annex B — Discrete Global Grid Reference System Definitions. |
| F | The …/dggs/{dggrsId} resource SHALL include a templated link in the linkTemplates array to request information for a particular zone using the link relation type [ogc-rel:dggrs-zone-info] and the template variable {zoneId}. |
| G | If the discrete global grid reference system (the combination of the discrete global grid and indexing system) is registered with an authority, the resource SHALL include a uri property corresponding to that registered discrete global grid reference system. |
| H | If the discrete global grid reference system is based on a particular coordinate reference system, the resource SHALL specify that CRS in a crs property, preferably as a URI (if one is available). |
| I | The Implementation SHALL include a short title property identifying the discrete global grid reference system intended for display to a human. |
| J | The Implementation SHALL include a description property providing a summary description of the discrete global grid reference system. |
| Identifier | /rec/core/max-refinement |
|---|---|
| Statement | For specifying a maximum refinement level for a discrete global grid reference system associated with a particular geospatial data resource: |
| A | For DGGS resources associated with a data source, the Implementation SHOULD include a maxRefinementLevel integer property in the …/dggs/{dggrsId} resource specifying the maximum refinement level at which the full resolution of the data can be retrieved (using a zone-depth relative depth of 0) and/or used for performing the most accurate zone queries (using that value for zone-level). |
See also Examples C.3.
7.4. Retrieving zone information (…/dggs/{dggrsId}/zones/{zoneId})
| Identifier | /req/core/zone-info |
|---|---|
| Included in | Requirements class 1: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/core |
| Statement | For retrieving information for a particular DGGRS zone: |
| A | The Implementation SHALL support an HTTP GET operation at a resource path ending with …/dggs/{dggrsId}/zones/{zoneId} providing information for valid individual zones of the discrete global grid reference system. |
| B | The zone information resource SHALL support a JSON representation. |
| C | The zone information resource SHALL include an id property corresponding to the {zoneId} resource path parameter. |
| D | The zone information resource SHALL include a link back to the corresponding DGGRS resource (…/dggs/{dggrsId}) using the [ogc-rel:dggrs] link relation type. |
| Identifier | /rec/core/zone-info |
|---|---|
| Statement | For recommending additional things that should be included in zone information resources: |
| A | The zone information resource SHOULD include a shapeType property indicating the shape type of the zone’s geometry (e.g., hexagon or pentagon). |
| B | The zone information resource SHOULD include a level property indicating the refinement level of the zone. |
| C | The zone information resource SHOULD include a crs property indicating the Coordinate Reference System (CRS) in which the geometry, centroid and bbox property are specified. |
| D | The zone information resource SHOULD include a centroid property indicating the centroid of the zone. In the JSON representation, this should be an array of two numbers in the CRS specified in crs. |
| E | The zone information resource SHOULD include a bbox property indicating the extent (envelope / bounding box) of the zone. In the JSON representation, this should be an array of four (4) coordinates for a DGGRS with two spatial dimensions or six (6) coordinates for a DGGRS with three spatial dimensions, in the CRS specified in crs. |
| F | The zone information resource SHOULD include links to its parent(s) zone(s) using link relation [ogc-rel:dggrs-zone-parent]. |
| G | The zone information resource SHOULD include links to its immediate children zone using link relation [ogc-rel:dggrs-zone-child]. |
| H | The zone information resource SHOULD include links to its neighboring zones using link relation [ogc-rel:dggrs-zone-neighbor]. |
| I | For a DGGS with two spatial dimensions, the zone information resource SHOULD include an areaMetersSquare property indicating the surface area of the zone in square meters. |
| J | For a DGGS with three spatial dimensions, the zone information resource SHOULD include a volumeMetersCube property indicating the volume of the zone in cubic meters. |
| K | For a temporal DGGS, the zone information resource SHOULD include a temporalDurationSeconds property indicating the amount of time covered by the zone in seconds. |
| L | The zone information resource SHOULD include a geometry property indicating the 2D and/or 3D spatial geometry of the zone using GeoJSON or OGC Features & Geometry JSON for the JSON encoding, and including intermediate points between the vertices of the geometry so as to accurately represent the shape of the zones for DGGRSs defined in a CRS other than the CRS used to express the coordinates of the vertices. The coordinates should be in the CRS specified in the crs property. |
| M | For a temporal DGGS, the zone information resource SHOULD include a temporalInterval property indicating the start and end time of the zone. |
| N | The implementation SHOULD support a GeoJSON and/or OGC Features & Geometry JSON representation of the zone information resource where the top-level object is a feature representing the zone geometry, a zoneID property of that feature corresponds to the textual identifier (the {zoneId}), the id of the feature corresponds to either a sequential feature identifier starting at 1, the textual identifier of the zone, or the 64-bit unsigned integer identifier of the zone, and the other properties described in this recommendation are properties of that feature. |
| O | For a zone associated with a particular collection, the Implementation SHOULD provide summary statistics (minimum, maximum, average, stdDev) pertaining to this zone for each field (fields of the range of a coverage, or relevant numeric properties of a feature collection) of the data. In the JSON encoding, this SHOULD be implemented as a statistics JSON dictionary property mapping field names to an object containing each statistic. |
| P | For a zone associated with a particular collection, the Implementation SHOULD provide areaMetersSquareWithData, volumeMetersCubeWithData, temporalDurationSecondsWithData properties corresponding to the respective properties defined above for the overall zones, but considering only the portions of the zone where there is data (e.g., regions of the zone excluding NODATA values for a gridded coverage, or within geometry for a feature collection). |
See also Examples C.4.
| Identifier | /rec/core/robots-txt |
|---|---|
| Statement | For discouraging automated crawling of zone information resources: |
| A | Implementations SHOULD include a robots.txt file at the root of their Web API discouraging robots from crawling the DGGS zone resources. |
| B | The content of that Robots.txt file SHOULD include Disallow: */dggs/*/zones/* to prevent crawling all DGGS resources under the /zones/ resource path. |
NOTE: The presence of a robots.txt file is not a security measure and relies on the voluntary compliance of well-intended crawlers to minimize unnecessary requests. This measure does not prevent malicious clients from overwhelming the server with numerous requests which may result in Denial of Service attacks.
8. Requirements Class “Data Retrieval”
8.1. Overview
The OGC API — DGGS “Data Retrieval” requirements class allows retrieving data from a specific DGGRS, that is a specific hierarchy of Discrete Global Grids combined with a particular zone indexing reference system (ZIRS), for an individual zone. It describes an HTTP GET operation, as well as its response. The selected DGGRS is listed as available and described in the Core requirements class, and conforms to OGC Topic 21.
The data for a particular zone is retrieved based on a URI template including a variable representing a Zone ID.
The resource from which data is retrieved could be for a particular collection of geospatial data (Collection DGGS Requirements Class) or for a dataset as a whole (Root DGGS Requirements Class).
The collection could also be virtual in nature, as described in the OGC API — Processes — Part 3: Workflows candidate Standard “Collection Output” requirements class, allowing to perform on-demand processing for a spatiotemporal region of interest associated with the zone for which data is being requested.
An implementation of this requirements class enables a client to ask a question of the type “What is here?”, where the “what” refers to data values associated with a particular dataset, collection, or processing workflow, and the here refers to a particular spatiotemporal region identified by the Zone ID.
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-retrieval |
|---|---|
| Target type | Web API |
| Conformance class | Conformance class A.2: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-retrieval |
| Prerequisite | https://www.opengis.net/spec/ogcapi-common-1/1.0/req/core |
| Normative statement | Requirement 4: /req/data-retrieval/zone-data |
8.2. Retrieving data from a zone (../dggs/{dggrsId}/zones/{zoneId}/data)
The following requirements describe how a client can retrieve data from a single DGGS zone at the resource path …/dggs/{dggrsId}/zones/{zoneId}/data.
| Identifier | /req/data-retrieval/zone-data |
|---|---|
| Included in | Requirements class 2: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-retrieval |
| Statement | For retrieving data for a single DGGS zone: |
| A | The Implementation SHALL support an HTTP GET operation at a resource path ending with …/dggs/{dggrsId}/zones/{zoneId}/data. |
| B | The Implementation SHALL include a templated link to this resource path in the “Core” …/dggs/{dggrsId} resource link templates, and regular link in the …/dggs/{dggrsId}/zones/{zoneId} resource links using the link relation type [ogc-rel:dggrs-zone-data] for all zones for which data is available. |
| C | The response of the HTTP GET operation SHALL have a status code of 200. |
| D | The content of the response SHALL be a data packet corresponding precisely to the area covered by the DGGS zone. |
| E | The selection of an encoding for the response SHALL be consistent with HTTP content negotiation. |
| F | The …/dggs/{dggrsId} resource SHALL include a defaultDepth property indicating the Implementation’s default depth for when the zone-depth query parameter is omitted. This default value could be any valid value and/or form as defined in the /req/data-custom-depths/zone-depth-parameter requirement (single depth, range of depths, or list of depths, relative to the {zoneId} hierarchy level). |
| G | Unless a zone-depth query parameter is specified, the response SHALL return a data packet consistent with this defaultDepth property, in accordance with the capabilities of the negotiated data packet encoding. |
See also Examples C.8.
8.3. Recommendation for a crs query parameter
The following recommendation describes how a server should support a crs query parameter for the …/zones/{zoneId}/data resource if the data can be returned in multiple applicable CRSs.
| Identifier | /rec/data-retrieval/crs |
|---|---|
| Statement | For retrieving data in alternate CRSs: |
| A | If the data is available in multiple CRSs, the Implementation SHOULD support a crs query parameter for the resource path ending with …/dggs/{dggrsId}/zones/{zoneId}/data. |
| B | This query parameter SHOULD support values specified either as full URIs (e.g., http://www.opengis.net/def/crs/OGC/1.3/CRS84) or as CURIEs (e.g., [OGC:CRS84], [EPSG:4326]). |
| C | The list of supported CRSs SHOULD be included in a crs property of the DGGS origin resource (such as the collection description) as an array of URIs or CURIEs. |
9. Requirements Class “Data Subsetting”
9.1. Overview
The OGC API — DGGS “Data Subsetting” requirements class extends the zone data retrieval requirements with the ability to subset data for additional dimensions beyond those defined by the DGGRS, for example along time or vertical dimension if those axes are not part the DGGRS definition, or along additional dimensions such as atmospheric pressure levels. Two query parameters are defined for this purpose: datetime (specifically for time) and subset (for any dimension, including time). Additionally, this requirements class defines the properties query parameter to select specific fields to include in the response instead of all fields which are included by defaults.
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-subsetting |
|---|---|
| Target type | Web API |
| Conformance class | Conformance class A.3: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-subsetting |
| Prerequisite | Requirements class 2: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-retrieval |
| Normative statements | Requirement 5: /req/data-subsetting/subset Requirement 6: /req/data-subsetting/datetime Requirement 7: /req/data-subsetting/properties |
9.2. subset query parameter
| Identifier | /req/data-subsetting/subset |
|---|---|
| Included in | Requirements class 3: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-subsetting |
| Statement | For specifying a multi-dimensional subset for the zone data being retrieved (excluding dimensions of the discrete global grid reference system): |
| A | The Implementation SHALL support a subset query parameter for the zone data retrieval operation (resource path ending with …/dggs/{dggrsId}/zones/{zoneId}/data) conforming to the following Augmented Backus Naur Form (ABNF) fragment:
SubsetSpec: "subset"=axisName(intervalOrPoint) |
| B | The Implementation SHALL support as an axis names`time` for a temporal dataset, unless this temporal axis is an axis of the discrete global grid reference system. |
| C | If a third vertical spatial dimension is supported (if the resource’s spatial extent bounding box is three dimensional) and that dimension is not part of the discrete global grid system definition, the Implementation SHALL also support a h dimension (elevation above the ellipsoid in EPSG:4979 or CRS84h) for geographic CRS and z for projected CRS, which are to be interpreted as the vertical axis in the CRS definition. |
| D | The Implementation SHALL support as axis names any additional dimension (beyond spatial and temporal) as described in the extent property of the collection or dataset description. |
| E | The Implementation SHALL return a 400 error status code if an axis name does not correspond to one of the axes of the Coordinate Reference System (CRS) of the data or an axis defined in the relevant extent property. |
| F | If a subset query parameter including any of the dimensions corresponding to the axes of the discrete global grid reference system is used, the server SHALL return a 400 client error. |
| G | The Implementation SHALL interpret multiple subset query parameters, as if all dimension subsetting values were provided in a single subset query parameter (comma separated). Example: subset=time("2018-02-12T16:00:0Z":"2018-02-12T20:00:00Z")&subset=atm_pressure_hpa(500:750) is equivalent to subset=time("2018-02-12T16:00:0Z":"2018-02-12T20:00:00Z"),atm_pressure_hpa(500:750) |
NOTE: When the interval values fall partially outside of the range of valid values defined by the CRS for the identified axis, the service is expected to return the non-empty portion of the data resulting from the subset.
See also Examples C.10.2.
9.3. datetime query parameter
| Identifier | /req/data-subsetting/datetime |
|---|---|
| Included in | Requirements class 3: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-subsetting |
| Statement | For specifying a time instant or interval for which to retrieve data from a zone for a non-temporal DGGS: |
| A | The Implementation SHALL support a datetime query parameter expressed corresponding to either a date-time instant or a time interval, conforming to the following syntax (using ABNF):
interval-bounded = instant "/" instant |
| B | The implementation SHALL support an instant defined as specified by RFC 3339, 5.6, with the exception that the server is only required to support the Z UTC time notation, and not required to support local time offsets. |
| C | Only the portions of the data within the specified interval SHALL be part of the zone data response, performing a trim operation for an interval or a slicing operation for an instant (in the case of a gridded coverage), or a filtering operation for feature data. |
| D | Time intervals unbounded at the start or at the end SHALL be supported using a double-dot (..) or an empty string for the start/end. |
| E | If a datetime query parameter is specified requesting zone data where no temporal dimension applies, the Implementation SHALL either ignore the query parameter or return a 4xx client error. |
Note: ISO 8601-2 distinguishes unbounded start/end timestamps (double-dot) and unknown start/end timestamps (empty string). For queries, an unspecified start/end has the same effect as an unbounded start/end.
Examples:
Example 1 — A date-time
February 12, 2018, 23:20:52 GMT:
datetime=2018-02-12T23:20:52Z
Example 2 — Intervals
February 12, 2018, 00:00:00 GMT to March 18, 2018, 12:31:12 GMT:
datetime=2018-02-12T00:00:00Z/2018-03-18T12:31:12Z
February 12, 2018, 00:00:00 UTC or later:
datetime=2018-02-12T00:00:00Z/..
March 18, 2018, 12:31:12 UTC or earlier:
datetime=../2018-03-18T12:31:12Z
See also Examples C.10.1.
9.4. properties query parameter
| Identifier | /req/data-subsetting/properties |
|---|---|
| Included in | Requirements class 3: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-subsetting |
| Statement | For specifying fields to include when retrieving zone data |
| A | The zone data retrieval operation SHALL support a properties query parameter where the value is a comma-separated list of fields to be returned. |
| B | The Implementation SHALL support selecting a field using the identifier corresponding to the top-level property keys of the logical schema of the resource associated with the DGGRS zone data request, and return 400 status code for an unrecognized selected field. |
| C | Only the selected fields SHALL be returned from the zone data request. |
| D | If the zone data encodings response can self-describe its list of fields (as with the schema property of the DGGS-JSON encoding), the field description SHALL correspond to the requested list of fields. |
| E | If the negotiated format of the response has a concept of field order, then the fields SHALL be in the same order as the requested list of selected fields. |
See also Examples C.10.3.
9.5. exclude-properties query parameter
| Identifier | /req/data-subsetting/exclude-properties |
|---|---|
| Statement | For including all but specific fields when retrieving zone data |
| A | The zone data retrieval operation SHALL support an exclude-properties query parameter where the value is a comma-separated list of fields not to be returned. |
| B | The Implementation SHALL support selecting fields not to return using the identifier corresponding to the top-level property keys of the logical schema of the resource associated with the DGGRS zone data request, and return 400 status code for an unrecognized selected field. |
| C | All but the selected fields SHALL be returned from the zone data request. |
| D | The Implementation SHALL return a 4xx error when using the both the properties and exclude-properties query parameters in the same request. |
10. Requirements Class “Data Custom Depths”
10.1. Overview
The OGC API — DGGS “Data Custom Depths” requirements class extends the zone data retrieval requirements class allowing a client to customize which depths to include as part of a zone data response relative to the requested hierarchy level for which data is being requested. This can be either a single depth, a range of depths, or a list of depths. The depths to include in the response are specified using the zone-depth query parameter. This depth customization ability can be restricted by the capability of the particular zone data response encoding negotiated.
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-custom-depths |
|---|---|
| Target type | Web API |
| Conformance class | Conformance class A.4: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-custom-depths |
| Prerequisite | Requirements class 2: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-retrieval |
| Normative statement | Requirement 9: /req/data-custom-depths/zone-depth |
10.2. zone-depth query parameter
| Identifier | /req/data-custom-depths/zone-depth |
|---|---|
| Included in | Requirements class 4: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-custom-depths |
| Statement | Query parameter to specify the DGGS refinement levels beyond the specified DGGS zone’s refinement level to include in the response, when retrieving data for that zone |
| A | The Implementation SHALL support a zone-depth query parameter for the HTTP GET operation on a resource path ending with …/dggs/{dggrsId}/zones/{zoneId}/data. |
| B | The Implementation SHALL accept the following types of values for the zone-depth query parameter:
|
| C | For each zone depth to be included in the response, the interpretation of a selected depth (whether requesting a single depth, a range of depths, or a list of depths) SHALL be:
|
| D | The association of zones of deeper hierarchy levels with the requested zone SHALL be based on the DGGRS reference system, which takes into consideration both the grid definition as well as the indexing system in use for the DGGS resource. |
| E | If a zone-depth is specified, the operation SHALL return the data at the refinement level(s) specified. |
NOTE 1: A use case for a zone-depth of 0 would be to query the single set of values for a specific DGGS zone.
NOTE 2: For use cases such as visualization and performing analysis over a certain area, a non-zero zone-depth would normally be used to avoid an overwhelming number of server round-trips. In this case, more than a single value would be returned for each zone request, with values returned for descendent zones at zone-depth levels deeper than the requested zone’s level. For example, requesting data for a level 10 zone with a zone-depth of 8 would return individual values for each level 18 zones contained within that level 10 zone being requested.
| Identifier | /rec/data-custom-depths/beyond-max-depth |
|---|---|
| Statement | For informing clients of a maximum relative depth: |
| A | For DGGS resources associated with a data source, the Implementation SHOULD include a maxRelativeDepth integer property in the …/dggs/{dggrsId} resource specifying the maximum relative depth at which data can be retrieved. |
| B | The Implementation SHOULD return a 4xx error for data retrieval beyond the maxRelativeDepth specified in the DGGRS description associated with the request. |
See also Examples C.9.
11. Requirements Class “Filtering Zone Data with CQL2”
11.1. Overview
The OGC API — DGGS “Filtering Zone Data with CQL2” requirements class defines a filter query parameter where an OGC Common Query Language (CQL2) expression can be used to filter the data returned for a zone, for example based on the properties / fields of the data, or for performing spatial and/or temporal intersections.
Requirements class 5: Requirements Class Filtering Zone Data with CQL2 | |
|---|---|
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-cql2-filter |
| Target type | Web API |
| Conformance class | Conformance class A.5: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-cql2-filter |
| Prerequisites | Requirements class 2: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-retrieval https://www.opengis.net/spec/cql2/1.0/req/cql2-text |
| Normative statement | Requirement 10: /req/data-cql2-filter/filter |
11.2. filter query parameter
The following requirements describe how a client can specify a filtering CQL2 expression to apply on a zone data retrieval request.
| Identifier | /req/data-cql2-filter/filter |
|---|---|
| Included in | Requirements class 5: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-cql2-filter |
| Statement | For specifying a CQL2 expression filtering the data returned from a zone data request: |
| A | The Implementation SHALL support a filter query parameter specified using the CQL2-Text encoding of the OGC Common Query Language for the zone data retrieval operation (resource path ending with …/dggs/{dggrsId}/zones/data). |
| B | For a rasterized representation, the data returned SHALL have null or NODATA values for sub-zones where the CQL2 expression evaluates to false when considering the geometry and the data of that sub-zone. |
| C | For a vector representation, the data returned SHALL only include features where the CQL2 expression evaluates to true when considering the geometry and the data of that sub-zone. |
| D | The CQL2 expression evaluator SHALL support the queryables declared in the JSON Schema resource linked to from the origin of the DGGRS resources using the [ogc-rel:queryables] link relation type. |
NOTE: The available queryables would typically include the fields of the data source being returned in the response.
See also Examples C.10.4.
12. Requirements Class “Zone Query”
12.1. Overview
The OGC API — DGGS “Zone Query” requirements class supports requesting the list of zones from a specific DGGRS, that is a specific hierarchy of Discrete Global Grids combined with a particular ZIRS, for which there is data available, or matching a particular query (e.g., using a filtering query parameter). This requirements class describes an HTTP GET operation, as well as its response. The selected DGGRS is listed as available and described in the Core requirements class, and conforms to OGC Topic 21. The list of zones from a Web API using this requirements class can either be for a particular collection of geospatial data, for a dataset as a whole, or in connection with OGC API — Processes — Part 3: Workflows & Chaining, the output of a processing workflow.
This requirements class enables a client to ask a question of the type “Where is it?”. The “where” refers to the spatiotemporal response encoded as a list of Zone IDs. The it refers to either the availability of data associated with a particular collection, dataset, or processing workflow (where the result itself could simply be this spatiotemporal region), as well as the evaluation of any additional filtering query expressed as per the CQL2 filtering requirements class.
Implementations of this requirements class are required to support at minimum the JSON encoding of zones list. This encoding provides an easy to implement, reasonably efficient and interoperable mechanism to exchange lists of zone identifiers. The JSON response consists of a simple object with a "zones" array property listing the zone identifiers as strings. The object can also include a "links" objects linking back to other resources of the DGGRS.
By default, zones are returned as a compacted list of zones, which recursively replaces children zones by their parent if all children of the parent are included in the response. A client can override this default behavior by setting the compact-zones query parameter to false.
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-query |
|---|---|
| Target type | Web API |
| Conformance class | Conformance class A.6: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/zone-query |
| Prerequisite | Requirements class 1: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/core |
| Normative statements | Requirement 11: /req/zone-query/zones-list Requirement 12: /req/zone-query/json-response Requirement 13: /req/zone-query/zone-level Requirement 14: /req/zone-query/compact-zones Requirement 15: /req/zone-query/parent-zone Requirement 16: /req/zone-query/bbox Requirement 17: /req/zone-query/bbox-crs Requirement 18: /req/zone-query/subset Requirement 19: /req/zone-query/subset-crs Requirement 20: /req/zone-query/datetime |
12.2. Listing zones (…/dggs/{dggrsId}/zones)
The following requirements describe how a client can retrieve the list of zones from which data is available at the resource path …/dggs/{dggrsId}/zones.
| Identifier | /req/zone-query/zones-list |
|---|---|
| Included in | Requirements class 6: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-query |
| Statement | For retrieving a list of DGGS zones. |
| A | The Implementation SHALL support an HTTP GET operation at a resource path ending with …/dggs/{dggrsId}/zones. |
| B | The Implementation SHALL include a link to this resource path in the “Core” …/dggs/{dggrsId} resource links using the link relation type https://www.opengis.net/def/rel/ogc/1.0/dggrs-zone-query. |
| C | The response of the HTTP GET operation SHALL have a status code of 200. |
| D | The content of the response SHALL be a list of zones fully covering where data is available (in the case where the resource is associated with a particular dataset), and matching any additional query parameters specified by the client (e.g., a filtering query parameter), without any redundancy. |
| E | Unless the zones are a compact list of zones (see compact-zones query parameter), the zones returned SHALL all be of the same DGGRS hierarchy level. |
| F | The selection of an encoding for the returned list of zones SHALL be consistent with HTTP content negotiation. |
| G | The Implementation SHALL support at minimum a JSON encoding (media type application/json). |
See also Examples C.5 and Examples C.6.
12.3. JSON zone list encoding
| Identifier | /req/zone-query/json-response |
|---|---|
| Included in | Requirements class 6: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-query |
| Statement | For returning a list of DGGS zones encoded as JSON |
| A | Every 200 response of the server for zone query with the media type application/json SHALL be a JSON document listing the textual identifiers for all zones matching the query. |
| B | The schema for the JSON document SHALL follow the JSON Schema for DGGS Zone Query described below, where the zone identifiers are strings within a zones array property within a JSON object. For example, { "zones": [ "1-E-14", "1-E-15", "1-F-14", "1-F-15", "1-F-16" ] }. |
| C | The links property SHALL include an [ogc-rel:dggrs] link to the Discrete Global Grid Reference System description resource. |
| D | The links property SHALL include an [ogc-rel:dggrs-definition] link to the DGGRS definition, using the schema defined in Annex B — DGGRS Definitions or a later version. |
{
"$schema" : "https://json-schema.org/draft/2020-12/schema",
"$id" : "https://schemas.opengis.net/ogcapi/dggs/part1/1.0/openapi/schemas/dggs-core/dggs-zones.json",
"type": "object",
"required": [ "zones" ],
"properties":
{
"zones" : { "type": "array", "items": { "type": "string" } },
"returnedAreaMetersSquare" : { "type": "number" },
"returnedVolumeMetersCube" : { "type": "number" },
"returnedVolumeMetersSquareSeconds" : { "type": "number" },
"returnedHyperVolumeMetersCubeSeconds" : { "type": "number" },
"links" :
{
"description": "Links to related resources."
"items": { "$ref" : "https://schemas.opengis.net/ogcapi/dggs/part1/1.0/openapi/schemas/common-core/link.yaml"
}
}
}
Listing 3 — JSON Schema for a DGGS Zone Query response
The following recommendation describes how the response should include the total surface area of the zones returned from the query (or volume / hypervolume in the case of spatiotemporal and/or 3D DGGS), excluding overlapping regions when returning compact zones.
| Identifier | /rec/zone-query/zone-total-area |
|---|---|
| Statement | For returning the total area (or volumes) occupied by zones returned by the query |
| A | The Implementation SHOULD indicate the total surface area (in the case of a 2D DGGS) or total (hyper)volume occupied (in the case of a 3D or 4D DGGS) occupied by the zones being returned, adding only once any overlaps which may occur for compact zone responses where zones are non-congruent (the total surface area is the same as what would be returned for the corresponding non-compacted list of zones at the refinement level of the zone query). |
| B | In the JSON response, for a 2D DGGS, the Implementation SHOULD include in the response a returnedAreaMetersSquare property indicating the total surface area occupied by the zones being returned, adding the overlaps which may occur for compact zone responses where zones are non-congruent only once. |
| C | In the JSON response, for a 3D DGGS, the Implementation SHOULD include in the response a returnedVolumeMetersCube property indicating the total volume occupied by the zones being returned, still counting overlapping regions only once. |
| D | In the JSON response, for a 2D + Time DGGS, the Implementation SHOULD include in the response a returnedVolumeMetersSquareSeconds property indicating the total volume occupied by the zones being returned, still counting overlapping regions only once. |
| E | In the JSON response, for a 3D + Time DGGS, the Implementation SHOULD include in the response a returnedHyperVolumeMetersCubeSeconds property indicating the total hypervolume occupied by the zones being returned, still counting overlapping regions only once. |
| Identifier | /rec/zone-json/additional-links |
|---|---|
| A | If DGGS Zone Data Retrieval is supported, the linkTemplates property SHOULD include an [ogc-rel:dggrs-zone-data] link with a {zoneId} variable to retrieve data from each of these DGGRS zones. |
| B | The links property SHOULD include an [ogc-rel:geodata] link for zone listing pertaining to a particular collection (for Collection DGGS requirements class). |
| Identifier | /rec/zone-json/zone-order |
|---|---|
| A | For responses where zones of multiple hierarchy levels are returned when compact-zones is true, the zones SHOULD be listed with coarser refinement levels first (larger zones). |
12.4. zone-level query parameter
The following requirements describe how a client can specify the DGGRS hierarchy level at which to retrieve the list of zones.
| Identifier | /req/zone-query/zone-level |
|---|---|
| Included in | Requirements class 6: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-query |
| Statement | For specifying a level at which to return a list of DGGS zones using a zone-level query parameter. |
| A | The Implementation SHALL support a zone-level query parameter for the zone query operation (resource path ending with …/dggs/{dggrsId}/zones). |
| B | If a compact zones list is returned (which is the default, unless the compact-zones query parameter is set to false), the zones returned in the response SHALL be of the DGGRS hierarchy level specified by the zone-level query parameter, or of a lower hierarchy level standing in for a compact representation of multiple zones at the requested hierarchy level. |
| C | If a non-compact zones list is returned (if the compact-zones query parameter is set to false), the zones returned in the response SHALL be of the DGGRS hierarchy level specified by the zone-level query parameter. |
12.5. compact-zones query parameter
By default, implementations return a compact list of zones where children zones fully covering a parent are recursively replaced by the parent zones, allowing to express large areas in a much more compact list of zones. The following requirements describe how a client can disable returning a compact list of zones.
| Identifier | /req/zone-query/compact-zones |
|---|---|
| Included in | Requirements class 6: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-query |
| Statement | For specifying whether to retrieve a list of DGGS zones using a compact-zones query parameter. |
| A | The Implementation SHALL support a Boolean compact-zones query parameter for the zone query operation (resource path ending with …/dggs/{dggrsId}/zones), where a value of true corresponds to the default behavior when the query parameter is not specified, and a value of false disables the use of compact-zones in the response. |
| B | When the compact-zones query parameter is set to false, the zones list response SHALL NOT be a compact list, and SHALL explicitly list every individual zone at the requested or default DGGRS hierarchy level. |
| C | When the compact-zones query parameter is set to true (or unspecified), the zones list response SHALL be a compact list, where children zones completely covering the area of a parent zone SHALL be replaced by that parent zone, in a recursive manner all the way to the lowest DGGRS hierarchy level. |
12.6. parent-zone query parameter for hierarchical exploration
The following requirement describes how a client can specify a parent zone to only return zones within this parent zone, enabling the exploration of a large list in a hierarchical manner (in combination with zone-level) as multiple requests and responses.
| Identifier | /req/zone-query/parent-zone |
|---|---|
| Included in | Requirements class 6: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-query |
| Statement | For specifying a parent zone within which to restrict zone listing using a parent-zone query parameter. |
| A | The Implementation SHALL support a parent-zone query parameter accepting a textual zone identifier. |
| B | When specified, the response SHALL NOT contain zones which are not this parent zone itself or a sub-zone of that zone. |
| Identifier | /rec/zone-query/zone-order |
|---|---|
| Statement | Recommendation to follow the DGGRS sub-zone ordering |
| A | When the parent-zone query parameter is used, the Implementation SHOULD return a list of zones ordered according to the canonical sub-zone ordering defined by the DGGRS (the same order used for encoding values for data retrieval in formats such as DGGS-JSON relying on a shared understanding of this order by the server/producer and client/consumer). |
12.7. limit query parameter for paging (recommendation)
The following recommendation describes how a client can specify a limit to the number of zones to be returned and page through a large list of zones as multiple requests and responses.
| Identifier | /rec/zone-query/limit |
|---|---|
| Statement | For specifying a paging limit for the list of zones using a limit query parameter. |
| A | The Implementation SHOULD support a limit integer query parameter, with a minimum value of 1. |
| B | The response SHOULD not contain more zones than specified by the optional limit query parameter (if specified). |
| C | If the API definition specifies a maximum value for the limit query parameter, the response SHOULD not contain more zones than this maximum value. |
| D | If the value of the limit query parameter is larger than the maximum value, this SHOULD NOT result in an error (but instead be replaced by the maximum as the query parameter value). |
| E | If using compact zones, the parent zones SHOULD count as a single zone, rather than the number of children zones they stand in for. |
| F | If an implementation does not return the full list of zones for the request, a link with relation type next SHOULD be included in a links array property of the response, which a client can request to resume listing the zones. |
12.8. bbox query parameter
| Identifier | /req/zone-query/bbox |
|---|---|
| Included in | Requirements class 6: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-query |
| Statement | For specifying a spatial bounding box for which to return a list of DGGS zones. |
| A | The Implementation SHALL support a bbox query parameter for the zone query operation (resource path ending with …/dggs/{dggrsId}/zones) with the characteristics defined in the OpenAPI Specification 3.0 fragment:
bbox: |
| B | bbox SHALL be interpreted as a comma separated list of four or six floating point numbers. If the bounding box consists of six numbers, the first three numbers are the coordinates of the lower bound corner of a three-dimensional bounding box and the last three are the coordinates of the upper bound corner. The axis order is determined by the bbox-crs query parameter value or longitude and latitude if the query parameter is missing (https://www.opengis.net/def/crs/OGC/1.3/CRS84 axis order for a 2D bounding box, https://www.opengis.net/def/crs/OGC/1.3/CRS84h for a 3D bounding box). For example in https://www.opengis.net/def/crs/OGC/1.3/CRS84 the order is left_lon, lower_lat, right_lon, upper_lat. |
| C | The returned list of zone IDs SHALL only contain zones inside or intersecting with the spatial extent of the geographical area of the bounding box. |
12.9. bbox-crs query parameter
| Identifier | /req/zone-query/bbox-crs |
|---|---|
| Included in | Requirements class 6: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-query |
| Statement | For specifying the CRS used for the bbox query parameter using the bbox-crs query parameter. |
| A | The list of zones resource SHALL support a bbox-crs query parameter specifying the CRS used for the bbox query parameter. |
| B | For Earth centric data, the Implementation SHALL support https://www.opengis.net/def/crs/OGC/1.3/CRS84 as a value. |
| C | If the bbox-crs is not indicated https://www.opengis.net/def/crs/OGC/1.3/CRS84 SHALL be assumed. |
| D | The native CRS (storageCrs) SHALL be supported as a value. Other conformance classes may allow additional values (see crs query parameter definition). |
| E | The CRS expressed as URIs or as safe CURIEs SHALL be supported. |
| F | If the bbox query parameter is not used, the bbox-crs query parameter SHALL be ignored. |
12.10. subset query parameter
| Identifier | /req/zone-query/subset |
|---|---|
| Included in | Requirements class 6: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-query |
| Statement | For specifying a multi-dimensional subset for which to return a list of DGGS zones. |
| A | The Implementation SHALL support a subset query parameter for the zone query operation (resource path ending with …/dggs/{dggrsId}/zones) conforming to the following Augmented Backus Naur Form (ABNF) fragment:
SubsetSpec: "subset"=axisName(intervalOrPoint) |
| B | The Implementation SHALL support as axis names Lat and Lon for geographic CRS and E and N for projected CRS, which are to be interpreted as the best matching spatial axis in the CRS definition. |
| C | If a third spatial dimension is supported (if the resource’s spatial extent bounding box is three dimensional), the Implementation SHALL also support a h dimension (elevation above the ellipsoid in EPSG:4979 or CRS84h) for geographic CRS and z for projected CRS, which are to be interpreted as the vertical axis in the CRS definition. |
| D | The Implementation SHALL support as axis names time for a temporal dataset. |
| E | The Implementation SHALL support as axis names any additional dimension (beyond spatial and temporal) as described in the extent property of the collection or dataset description. |
| F | The Implementation SHALL return a 400 error status code if an axis name does not correspond to one of the axes of the Coordinate Reference System (CRS) of the data or an axis defined in the relevant extent property. |
| G | For a CRS where an axis can wrap around, such as subsetting across the dateline (anti-meridian) in a geographic CRS, a low value greater than high SHALL be supported to indicate an extent crossing that wrapping point. |
| H | The Implementation SHALL interpret the coordinates as values for the named axis of the CRS specified in the subset-crs query parameter value or in https://www.opengis.net/def/crs/OGC/1.3/CRS84 (https://www.opengis.net/def/crs/OGC/1.3/CRS84h for vertical dimension) if the subset-crs query parameter is missing. |
| I | If the subset query parameter including any of the dimensions corresponding to those of the map bounding box is used with a bbox, the server SHALL return a 400 client error. |
| J | The Implementation SHALL interpret multiple subset query parameters, as if all dimension subsetting values were provided in a single subset query parameter (comma separated). Example: subset=Lat(-90:90)&subset=Lon(-180:180) is equivalent to subset=Lat(-90:90),Lon(-180:180) |
NOTE 1: A subset query parameter for https://www.opengis.net/def/crs/OGC/1.3/CRS84 will read as subset=Lon(left_lon:right_lon),Lat(lower_lat:upper_lat).
NOTE 2: When the interval values fall partially outside of the range of valid values defined by the CRS for the identified axis, the service is expected to return the non-empty portion of the resource resulting from the subset.
NOTE 3: For the operation of returning a list of zone IDs, there normally is no value in preserving dimensionality, therefore a slicing operation (using the point notation) is usually equivalent to a trimming operation (using the interval notation) when the low and high bounds of an interval are the same. Therefore, use of the point notation is encouraged in these cases.
| Identifier | /rec/zone-query/subset-crs-axis-names |
|---|---|
| A | The names of the axis SHOULD be the abbreviated names of the axis in the CRS definition (e.g., the ones defined in the EPSG database). |
| B | ‘e’ (in lowercase), ‘X’ (lowercase/uppercase) or ‘Easting’ (lowercase/uppercase) SHOULD be interpreted as synonymous of ‘E’. |
| C | ‘n’ (in lowercase) or ‘Y’ (lowercase/uppercase) or ‘Northing’ (lowercase/uppercase) SHOULD be interpreted as synonymous of ‘N’. |
| D | ‘Long’ (lowercase/uppercase) or ‘Longitude’ SHOULD be interpreted as synonymous of ‘Lon’. |
| E | ‘Latitude’ SHOULD be interpreted as synonymous of ‘Lat’. |
12.11. subset-crs query parameter
| Identifier | /req/zone-query/subset-crs |
|---|---|
| Included in | Requirements class 6: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-query |
| Statement | For specifying the CRS used for the subset query parameter using the subset-crs query parameter. |
| A | The zone listing operation SHALL support a query parameter subset-crs identifying the CRS in which the subset query parameter is specified with a URI or safe CURIE. |
| B | For Earth centric data, https://www.opengis.net/def/crs/OGC/1.3/CRS84 as a value SHALL be supported. |
| C | If the subset-crs is not indicated, https://www.opengis.net/def/crs/OGC/1.3/CRS84 SHALL be assumed. |
| D | The native CRS (storageCrs) SHALL be supported as a value. Other requirements classes may allow additional values (see crs query parameter definition). |
| E | CRSs expressed as URIs or as safe CURIEs SHALL be supported. |
| F | If no subset query parameter referring to an axis of the CRS is used, the query subset-crs SHALL be ignored. |
12.12. datetime query parameter
| Identifier | /req/zone-query/datetime |
|---|---|
| Included in | Requirements class 6: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-query |
| Statement | For specifying a multi-dimensional subset for which to return a list of DGGS zones. |
| A | The Implementation SHALL support a datetime query parameter expressed corresponding to either a date-time instant or a time interval, conforming to the following syntax (using ABNF):
interval-bounded = instant "/" instant |
| B | The implementation SHALL support an instant defined as specified by RFC 3339, 5.6, with the exception that the server is only required to support the Z UTC time notation, and not required to support local time offsets. |
| C | Only the zones with data whose geometry intersect with the specified temporal interval SHALL be part of the zone list response. |
| D | Time intervals unbounded at the start or at the end SHALL be supported using a double-dot (..) or an empty string for the start/end. |
| E | If a datetime query parameter is specified requesting zone data where no temporal dimension applies, the Implementation SHALL either ignore the query parameter or return a 4xx client error. |
13. Requirements Class “Filtering Zone Queries with CQL2”
13.1. Overview
The OGC API — DGGS “Filtering Zone Queries with CQL2” requirements class defines a filter query parameter where an OGC Common Query Language (CQL2) expression can be used to filter the list of returned zones. Such CQL2 queries enable filtering based on the properties / fields of the data, or on spatiotemporal intersections.
Requirements class 7: Requirements Class Filtering Zone Queries with CQL2 | |
|---|---|
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-query-cql2-filter |
| Target type | Web API |
| Conformance class | Conformance class A.7: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/zone-query-cql2-filter |
| Prerequisites | Requirements class 6: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-query https://www.opengis.net/spec/cql2/1.0/req/cql2-text |
| Normative statement | Requirement 21: /req/zone-query-cql2-filter/filter |
13.2. filter query parameter
The following requirements describe how a client can specify a filtering CQL2 expression querying a list of zones.
| Identifier | /req/zone-query-cql2-filter/filter |
|---|---|
| Included in | Requirements class 7: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-query-cql2-filter |
| Statement | For specifying a CQL2 expression filtering the zones returned from a zone query: |
| A | The Implementation SHALL support a filter query parameter specified using the CQL2-Text encoding of the OGC Common Query Language for the zone query operation (resource path ending with …/dggs/{dggrsId}/zones). |
| B | The list of returned zones SHALL only be those for which the CQL2 expression evaluates to true when considering the geometry and the data of the DGGS zones resource being queried. |
| C | The CQL2 expression evaluator SHALL support the queryables declared in the JSON Schema resource linked to from the origin of the DGGRS resources using the [ogc-rel:queryables] link relation type. |
NOTE: The available queryables would typically include the fields of the data source, which may also be retrieved using the Data Retrieval requirements class.
See also Examples C.7.
14. Requirements Class “Root DGGS”
14.1. Overview
The OGC API — DGGS “Root DGGS” Requirements Class defines the availability of DGGS resources applying to a whole dataset or API, as defined by OGC API — Common — Part 1: Core.
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/root-dggs |
|---|---|
| Target type | Web API |
| Conformance class | Conformance class A.8: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/root-dggs |
| Prerequisite | https://www.opengis.net/spec/ogcapi-common-1/1.0/req/core |
| Normative statement | Requirement 22: /req/root-dggs/dggs |
14.2. Root DGGS (/dggs)
| Identifier | /req/root-dggs/dggs |
|---|---|
| Included in | Requirements class 8: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/root-dggs |
| Statement | For API/dataset-wide DGGS resources: |
| A | The Implementation SHALL support the resource paths and associated HTTP methods defined in the “Core” requirements class, as well as any additional resources defined in other requirements classes to which the Implementation declares conformance, for the root of the API as an origin. If the API allows to retrieve and/or query data, this means that the data returned or queried considers all collections comprising the dataset (unless an extension is used to select specific collections e.g., using a collections query parameter). The root DGGRS origin can also be used in API deployment not associated with any dataset, solely for the purpose of exploring and demonstrating the DGGRS. |
| B | The Implementation SHALL include a link to the list of available DGGRSs for the API/dataset at /dggs in the links of the landing page using the link relation type [ogc-rel:dggrs-list]. |
| C | If the API deployment supports querying or retrieving data from a dataset, the /dggs and /dggs/{dggrsId} resources SHALL include a link to the landing page using the link relation type [ogc-rel:dataset]. |
15. Requirements Class “Collection DGGS”
15.1. Overview
The OGC API — DGGS “Collection DGGS” Requirements Class defines the availability of DGGS resources applying to one or more collections of geospatial data, as defined by OGC API — Common — Part 2: Geospatial data.
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/collection-dggs |
|---|---|
| Target type | Web API |
| Conformance class | Conformance class A.9: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/collection-dggs |
| Prerequisite | https://www.opengis.net/spec/ogcapi-common-2/1.0/req/collections |
| Normative statement | Requirement 23: /req/collection-dggs/dggs |
15.2. Collection DGGS (/collections/{collectionId}/dggs)
| Identifier | /req/collection-dggs/dggs |
|---|---|
| Included in | Requirements class 9: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/collection-dggs |
| Statement | For collection DGGS resources: |
| A | The Implementation SHALL support the resource paths and associated HTTP methods defined in the “Core” requirements class, as well as any additional resources defined in other requirements classes to which the Implementation declares conformance, for at least one collection of the dataset offered by the API deployment. |
| B | The Implementation SHALL include a link to the list of available DGGRSs for the collection at /collections/{collectionId}/dggs in the links of the collection using the link relation type [ogc-rel:dggrs-list]. |
| C | The /collections/{collectionId}/dggs and /collections/{collectionId}/dggs/{dggrsId} resources SHALL include a link to the collection using the link relation type [ogc-rel:geodata]. |
See also Examples C.1.
16. Requirements Classes for Encodings of Zone data
The OGC API — DGGS Standard does not mandate any particular encoding or format in which to return the …/dggs/{dggrsId}/zones/{zoneId}/data resources. DGGS Zone Data can be encoded in any suitable data format. However, the Standard does define requirements classes for zone data encodings which are expected to be commonly supported in implementations of this standard. These requirements classes include:
For data rasterized to DGGRS sub-zones:
Depending on a selected profile, for data either rasterized to DGGRS sub-zones, or rasterized data output readily usable in non-DGGS systems (or to facilitate interoperability with other DGGHs):
For 2D rasterized data output readily usable in non-DGGS systems or to facilitate interoperability with other DGGHs:
For vector features whose geometry coordinates are quantized to DGGRS sub-zones:
For vector features output readily usable in non-DGGS systems or to facilitate interoperability with other DGGHs:
GeoJSON Data — including support for Features & Geometry JSON (JSON-FG) output as a recommendation
16.1. Media Types (for zone data)
A table of the media types used in the encoding of the Zone Data requirements classes defined in this Standard follows.
Table 3 — Media Types used for zone data encoding requirements classes
| Encoding | Media type |
| DGGS-JSON zone data | application/json |
| DGGS-UBJSON zone data | application/ubjson |
| DGGS-JSON-FG zone data | application/geo+json (with profile query parameter values of jsonfg-dggs, jsonfg-dggs-plus, jsonfg-dggs-zoneids or jsonfg-dggs-zoneids-plus) |
| DGGS-UBJSON-FG zone data | application/geo+ubjson (with profile query parameter values of jsonfg-dggs, jsonfg-dggs-plus, jsonfg-dggs-zoneids or jsonfg-dggs-zoneids-plus) |
| GeoJSON / JSON-FG data | application/geo+json (without profile query parameter, or with values of rfc7946, jsonfg or jsonfg-plus) |
| GeoTIFF data | image/tiff; application=geotiff |
| netCDF zone data | application/netcdf (rasterized to sub-zones for profile query parameter values of netcdf3-dggs, netcdf3-dggs-zoneids, netcdf4-dggs, netcdf4-dggs-zoneids ) |
| Zarr zone data | application/zarr+zip (rasterized to sub-zones for profile query parameter values of zarr2-dggs or zarr2-dggs-zoneids) |
| CoverageJSON zone data | application/prs.coverage+json (rasterized to sub-zones for profile query parameter values of covjson-dggs or covjson-dggs-zoneids) |
| PNG zone data | image/png |
| JPEG XL zone data | image/jxl |
16.2. Requirements Class “DGGS-JSON Zone data encoding” (for data rasterized to sub-zones)
16.2.1. Overview
The DGGS-JSON Zone Data encoding requirements class defines support for encoding a DGGS Zone data response in JSON, using a schema defined below named “DGGS-JSON”.
This encoding is intended to support one-to-one mapping of sub-zones values, for one or more zone depths, regardless of zone geometry type, in a human-readable format.
Values are encoded as a one-dimensional array following a sub-zone order defined by the DGGRS.
Example encodings follow:
{
"$schema" : "https://schemas.opengis.net/ogcapi/dggs/1.0/core/schemas/dggs-json/dggs-json.json",
"dggrs": "https://www.opengis.net/def/dggrs/OGC/1.0/ISEA3H",
"zoneId": "C0-2B-A",
"depths": [ 0, 1 ],
"schema":
{
"$schema" : "https://json-schema.org/draft/2020-12/schema",
"$id" : "https://example.com/ogcapi/collections/climate/schema",
"title" : "Temperature",
"type": "object",
"properties":
{
"t": {
"type": "number",
"title": "air temperature in celsius",
"x-ogc-propertySeq" : 1,
"x-ogc-definition": "https://qudt.org/vocab/quantitykind/Temperature",
"x-ogc-unit": "C"
}
}
},
"values":
{
"t": [
{
"depth": 0,
"shape": { "count": 1, "subZones": 1 },
"data": [ 22.8 ]
},
{
"depth": 1,
"shape": { "count": 7, "subZones": 7 },
"data": [ 25.1, 25.8, 22.0, 23.1, 22.8, 20.0, 17.1 ]
}
]
}
}
Listing 7 — Example encoding for DGGS-JSON
{
"$schema" : "https://schemas.opengis.net/ogcapi/dggs/1.0/core/schemas/dggs-json/dggs-json.json",
"dggrs": "https://www.opengis.net/def/dggrs/OGC/1.0/ISEA3H",
"zoneId": "C0-2B-A",
"depths": [ 0, 1 ],
"schema":
{
"$schema" : "https://json-schema.org/draft/2020-12/schema",
"$id" : "https://example.com/ogcapi/collections/climate/schema",
"title" : "Climate Variables",
"type": "object",
"properties":
{
"rh": {
"type": "number",
"title": "relative humidity",
"x-ogc-propertySeq" : 1,
"x-ogc-definition": "https://qudt.org/vocab/quantitykind/RelativeHumidity"
},
"t": {
"type": "number",
"title": "air temperature in celsius",
"x-ogc-propertySeq" : 2,
"x-ogc-definition": "https://qudt.org/vocab/quantitykind/Temperature",
"x-ogc-unit": "C"
},
"ua": {
"type": "number",
"title": "Eastward wind",
"x-ogc-propertySeq" : 3,
"x-ogc-definition": "https://qudt.org/vocab/quantitykind/Speed",
"x-ogc-unit": "m/s"
},
"va": {
"type": "number",
"title": "Northward wind",
"x-ogc-propertySeq" : 4,
"x-ogc-definition": "https://qudt.org/vocab/quantitykind/Speed",
"x-ogc-unit": "m/s"
}
}
},
"dimensions" : [
{
"name": "time",
"interval" : [ "2020-01-01", "2020-04-30" ],
"grid" : { "cellsCount" : 4, "firstCoordinate" : "2020-01-01", "resolution" : "P1M" }
},
{
"name": "pressure",
"definition": "https://qudt.org/vocab/quantitykind/AtmosphericPressure",
"unit" : "hPa",
"interval" : [ 850.0, 50.0 ],
"grid" : { "cellsCount" : 3, "coordinates" : [ 850.0, 250.0, 50.0 ] }
}
],
"values":
{
"rh": [
{
"depth": 0,
"shape": { "count": 9, "subZones": 1, "dimensions": { "time": 4, "pressure": 3 } },
"data": [
25.1, 25.8, 22.0, 23.1, 22.8, 20.0, 17.1, 12.8, 14.0, 24.1, 13.8, 12.0
]
},
{
"depth": 1,
"shape": { "count": 84, "subZones": 7, "dimensions": { "time": 4, "pressure": 3 } },
"data": [
23.2, 25.8, 22.0, 22.8, 20.0, 22.0, 17.1, 12.8, 14.0, 23.1, 17.0, 24.0,
22.1, 23.8, 22.0, 28.0, 23.2, 22.8, 18.0, 22.0, 17.1, 12.8, 12.0, 17.0,
25.2, 25.8, 22.0, 27.0, 23.1, 22.8, 21.0, 20.0, 16.1, 12.8, 14.0, 12.0,
24.1, 24.8, 21.0, 23.0, 23.3, 22.8, 23.0, 22.0, 17.1, 12.8, 13.0, 17.0,
25.1, 25.8, 22.0, 21.0, 22.1, 22.8, 22.0, 21.0, 13.1, 12.8, 14.0, 14.0,
26.1, 25.8, 20.0, 22.0, 23.5, 22.8, 21.0, 22.0, 17.1, 12.8, 11.0, 17.0,
24.1, 25.4, 20.3, 23.0, 22.5, 22.9, 20.9, 21.7, 17.4, 12.9, 11.5, 17.9
]
}
],
"t": [ ... ], "ua": [ ... ], "va": [ ... ]
}
}
Listing 8 — A more complex example encoding for DGGS-JSON with more variables and additional dimensions beyond those of the DGGRS
Requirements class 10: Requirements Class DGGS-JSON Zone Data | |
|---|---|
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-json |
| Target type | Web API |
| Conformance class | Conformance class A.10: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-json |
| Prerequisites | JSON Requirements class 2: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-retrieval |
| Normative statement | Requirement 24: /req/data-json/content |
16.2.2. DGGS-JSON Zone Data
| Identifier | /req/data-json/content |
|---|---|
| Included in | Requirements class 10: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-json |
| Statement | For encoding zone data as DGGS-JSON: |
| A | Every 200 response of the server for zone data with the media type application/json SHALL be a JSON document representing the data values for all selected fields of each included sub-zone. |
| B | The schema for the JSON document SHALL follow the JSON Schema for DGGS-JSON described below. |
| C | Every zone depth requested using the zone-depth query parameter SHALL be included in the response. |
| D | At every depth, each individual value SHALL correspond exactly to the data sampled representative of that sub-zone. |
| E | The list of data values SHALL follow the default zone order as specified by the Discrete Global Grid Reference System (for example based on a scanline or space-filling curve defined therein) for which the request is made. |
| F | Null values SHALL use the null JSON value. |
{
"$schema" : "https://json-schema.org/draft/2020-12/schema",
"$id" : "https://schemas.opengis.net/ogcapi/dggs/1.0/core/schemas/dggs-json/dggs-json.json",
"type": "object",
"properties":
{
"dggrs" : { "type": "string", "format": "uri" },
"zoneId" : { "type": "string" },
"depths" : { "type": "array", "items": { "type": "integer", "minimum": 0 } },
"schema" : { "$ref": "https://json-schema.org/draft/2020-12/schema" },
"dimensions" :
{
"type": "array",
"items":
{
"type": "object",
"properties":
{
"name": { "type": "string" },
"definition": { "type": "string", "format": "uri" },
"unit": { "type": "string" },
"unitLang": { "type": "string", "format": "uri" },
"grid":
{
"required": [ "cellsCount" ],
"oneOf": [
{ "required": [ "resolution", "firstCoordinate" ] },
{ "required": [ "coordinates" ] }
],
"type": "object",
"properties":
{
"boundsCoordinates": {
"items": {
"type": "array",
"items": {
"oneOf": [
{ "nullable": true, "type": "number" },
{ "nullable": true, "type": "string" }
]
},
"maxItems": 2,
"minItems": 2
},
"type": "array"
},
"cellsCount" : { "type": "integer" },
"resolution" : {
"oneOf": [
{ "type": "number" },
{ "type": "string" }
]
},
"firstCoordinate": {
"oneOf": [
{ "type": "number" },
{ "type": "string" }
]
},
"relativeBounds": {
"items": {
"oneOf": [
{ "type": "number" },
{ "type": "string" }
]
},
"maxItems": 2,
"minItems": 2,
"type": "array"
},
"coordinates": {
"type": "array",
"items": {
"oneOf": [
{ "type": "number" },
{ "type": "string" }
]
}
}
}
},
"interval": {
"type": "array",
"maxItems": 2,
"minItems": 2,
"items": {
"oneOf": [
{ "type": "number", "nullable": true },
{ "type": "string", "nullable": true }
]
}
}
},
"required": [ "name", "interval", "grid" ]
}
},
"values" :
{
"additionalProperties":
{
"type": "array",
"items":
{
"type": "object",
"required": [ "data" ],
"properties":
{
"depth": { "type": "integer" },
"shape":
{
"type": "object",
"properties":
{
"count": { "type": "integer" },
"subZones": { "type": "integer" },
"dimensions":
{
"type": "object",
"additionalProperties": { "type": "integer" }
}
},
"required": [ "count", "subZones" ]
},
"data":
{
"type": "array",
"items":
{
"type": "number",
"nullable": true
}
}
}
}
}
}
},
"required": [ "dggrs", "zoneId", "depths", "values" ]
}
Listing 9 — JSON Schema for DGGS-JSON
IMPORTANT
For DGGS-JSON containing additional dimensions, the one-dimensional array of values is ordered in a sub-zone order major manner. This is so all values of a particular field for a given sub-zone are regrouped together. Values for the first dimensions listed in the dimensions array are then regrouped together, followed by additional dimensions as they appear in order in the dimensions array.
16.3. Requirements Class “DGGS-UBJSON Zone data encoding” (for data rasterized to sub-zones)
16.3.1. Overview
The DGGS-UBJSON Zone Data encoding requirements class defines support for encoding a DGGS Zone data response using the same JSON structure as the above JSON data requirements class but using the binary UBJSON encoding.
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-ubjson |
|---|---|
| Target type | Web API |
| Conformance class | Conformance class A.11: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-ubjson |
| Prerequisites | https://ubjson.org/ Requirements class 2: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-retrieval |
| Normative statement | Requirement 25: /req/data-ubjson/content |
16.3.2. DGGS-UBJSON Zone Data
| Identifier | /req/data-ubjson/content |
|---|---|
| Included in | Requirements class 11: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-ubjson |
| Statement | For encoding zone data as DGGS-UBJSON |
| A | Every 200 response of the server for zone data with the media type application/ubjson SHALL be a Universal Binary JSON document representing the data values for all selected fields of each included sub-zone. |
| B | The schema for the UBJSON document SHALL follow the same JSON Schema as for DGGS-JSON described above. |
| C | Every zone depth requested using the zone-depth query parameter SHALL be included in the response. |
| D | At every depth, each individual value SHALL correspond exactly to the data sampled representative of that zone geometry. |
| E | The list of data values SHALL follow the default zone order as specified by the Discrete Global Grid Reference System (for example based on a scanline or space-filling curve defined therein) for which the request is made. |
| F | Null values SHALL use the null JSON value. |
The py-ubjson tool can be used to easily convert between JSON and UBJSON. After installing with pip3 install py-ubjson, a DGGS-JSON file can be converted to DGGS-UBJSON with ubjson fromjson zoneData.dggs.json, and a DGGS-UBJSON file can be converted to DGGS-JSON with ubjson tojson zoneData.dggs.ubj.
16.4. Requirements Class “DGGS-JSON-FG Zone data encoding” (for geometry coordinates quantized to sub-zones)
16.4.1. Overview
The DGGS-JSON-FG Zone Data encoding requirements class defines support for encoding a DGGS Zone data response for vector features in JSON. This is accomplished by extending OGC Features & Geometry JSON with the concepts of DGGRS, reference parent zone, relative depth and deterministic sub-zone order, allowing to encode coordinates pairs as local sub-zone indices. Alternatively, coordinates can be encoded using global zone IDs.
DGGS-JSON-FG Zone Data is intended to support efficient encoding of vector geometry at arbitrary precision using finer grids to locally address the inside of the reference parent zones. This is done in a manner agnostic of the DGGRS (which needs to define a deterministic sub-zone order), in a human-readable format sharing as much as possible with existing practice for exchanging geospatial vector data in JSON.
An Implementation may support a DGGS-JSON-FG representation where DGGS-quantized coordinates are specified either as global zone identifiers or as local indices into the deterministic zone order, and may also support GeoJSON / JSON-FG compatibility modes where coordinates are additionally specified as positions on spatiotemporal axes for interoperability with non-DGGS clients.
A profile query parameter can be used by clients to request a particular DGGS-JSON-FG representation from Implementations supporting multiple options:
jsonfg-dggs: DGGS-JSON-FG with dggsPlace coordinates corresponding to local sub-zone indices
jsonfg-dggs-plus: DGGS-JSON-FG with dggsPlace coordinates corresponding to local sub-zone indices, in addition to GeoJSON (geometry) and/or JSON-FG compatibility mode (place)
jsonfg-dggs-zoneids: DGGS-JSON-FG with dggsPlace coordinates corresponding to global textual identifiers
jsonfg-dggs-zoneids-plus: DGGS-JSON-FG with dggsPlace coordinates corresponding to global textual identifiers, in addition to GeoJSON (geometry) and/or JSON-FG compatibility mode (place)
Example encodings follow:
{
"conformsTo": [
"https://www.opengis.net/spec/json-fg-1/0.2/conf/core",
"https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-dggs-jsonfg"
],
"links": [
{
"rel" : "profile",
"href" : "https://www.opengis.net/def/profile/ogc/0/jsonfg-dggs"
}
],
"dggrs": "[ogc-dggrs:ISEA3H]",
"zoneId": "I0-1EEBFA7-C",
"depth": "15",
"type" : "FeatureCollection",
"features" : [ {
"type" : "Feature",
"id" : 2305843009218664049,
"geometry" : null,
"place" : null,
"time" : null,
"dggsPlace" : {
"type" : "LineString",
"coordinates" : [ 13866054, 13899376, 13953688 ]
},
"properties" : {
"highway" : "service",
"name" : "Parliament Road",
"name:fr" : "chemin Parliament",
"access" : "no"
}
}, {
"type" : "Feature",
"id" : 2305843009218664071,
"geometry" : null,
"place" : null,
"time" : null,
"dggsPlace" : {
"type" : "LineString",
"coordinates" :
...
Listing 10 — Example encoding of DGGS-JSON-FG for OpenStreetMap data
{
"conformsTo": [
"https://www.opengis.net/spec/json-fg-1/0.2/conf/core",
"https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-dggs-jsonfg"
],
"links": [
{
"rel" : "profile",
"href" : "https://www.opengis.net/def/profile/ogc/0/jsonfg-dggs"
}
],
"dggrs": "[ogc-dggrs:ISEA3H]",
"zoneId": "B0-5-A",
"depth": "15",
"geometryDimension": 2,
"type": "FeatureCollection",
"features": [
{
"type": "Feature",
"id": 1,
"properties": {
"scalerank": 0,
"featurecla": "Bathymetry"
},
"geometry" : null,
"place": null,
"time" : null,
"dggsPlace": {
"type": "MultiPolygon",
"coordinates": [
[
[ 14355360, 14355250, 14355141, 14355032, 14354922, 14354813, ...
Listing 11 — Example encoding of DGGS-JSON-FG for Natural Earth bathymetry in the arctic
Requirements class 12: Requirements Class DGGS-JSON-FG Zone Data | |
|---|---|
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-dggs-jsonfg |
| Target type | Web API |
| Conformance class | Conformance class A.12: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-dggs-jsonfg |
| Prerequisites | JSON Requirements class 2: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-retrieval https://www.opengis.net/spec/json-fg-1/0.3/req/core |
| Normative statement | Requirement 26: /req/data-dggs-jsonfg/content |
16.4.2. DGGS-JSON-FG Zone Data
| Identifier | /req/data-dggs-jsonfg/content |
|---|---|
| Included in | Requirements class 12: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-dggs-jsonfg |
| Statement | For encoding zone data as DGGS-JSON-FG |
| A | The Implementation SHALL support zone data requests negotiating an application/geo+json media type combined with a profile query parameter with a value of jsonfg-dggs, jsonfg-dggs-plus, jsonfg-dggs-zoneids or jsonfg-dggs-zoneids-plus allowing a client to request a DGGS-JSON-FG response. |
| B | Every 200 response of the server for DGGS-JSON-FG zone data requests SHALL be an extended Features & Geometry JSON (JSON-FG) document representing the vector features within the requested zone. |
| C | The JSON document SHALL follow the JSON Schema for JSON-FG, with geometry stored in a dggsPlace property mirroring the JSON-FG place schema and supporting all of the same feature types, but where coordinates use sub-zone indices (for profile=jsonfg-dggs or jsonfg-dggs-plus) or global textual zone identifiers (for profile=jsonfg-dggs-zoneids or jsonfg-dggs-zoneids-plus) as described in later parts of this requirement. |
| D | For profile=jsonfg-dggs-plus and jsonfg-dggs-zoneids-plus, the JSON document SHALL also include geometry stored in geometry or place using traditional coordinate reference system coordinates for compatibility. |
| E | The JSON document SHALL additionally contain a dggrs property set to the URI or CURIEs of the DGGRS of the response, which replaces the coordRefSys property and concept. |
| F | The JSON document SHALL additionally contain a zoneId property indicating the requested reference zone. |
| G | The JSON document SHALL additionally contain a depth property corresponding to the relative zone depth (as specified in the single depth format of the OGC API — DGGS zone-depth query parameter for zone data retrieval), determining how coordinates are resolved from sub-zone indices (in the case of profile=jsonfg-dggs and jsonfg-dggs-plus), and as a result, their precision. |
| H | For profile=jsonfg-dggs and jsonfg-dggs-plus, the JSON document SHALL contain a dggsPlace property specifying geometry using local sub-zone indices ranging from 1 to the number of sub-zones within the reference parent zone at the declared depth, based on the deterministic sub-zone order of the DGGRS. |
| I | For profile=jsonfg-dggs-zoneids and jsonfg-dggs-zoneids-plus, the JSON document SHALL contain a dggsPlace property specifying geometry using global textual zone identifiers (as defined in the DGGRS zone indexing reference system) at the declared depth. |
| J | When all spatial coordinates are dimensions of the DGGRS, the array of coordinates including the square brackets SHALL be replaced by the local index or global identifier of the sub-zone within which the coordinates are located. |
| K | When additional spatial coordinates that are not part of the DGGRS, such as elevation above ground for a 2D DGGRS, are needed to define the geometry coordinates, only the coordinates corresponding to DGGRS dimensions SHALL be replaced by the local index or global identifier of the sub-zone. |
| L | Only features fully or partly located within the reference zone SHALL be included. |
| M | For feature geometry intersecting the boundaries of the reference zone, the sub-zone within which the intersection is located SHALL be included, with a separate single 0 special sub-zone index (in the case of profile=jsonfg-dggs and jsonfg-dggs-plus) or a null value (in the case of profile=jsonfg-dggs-zoneids and jsonfg-dggs-zoneids-plus) representing all outside points before a point inside, after a point inside, or in between two inside points. |
| N | For geometry in two or more dimensions with an outside point (identified by a 0 sub-zone index for profile=jsonfg-dggs and jsonfg-dggs-plus, or null for profile=jsonfg-dggs-zoneids and jsonfg-dggs-zoneids-plus) and which is necessarily between two contour points, the portion of the zone edge(s) between the exit and entry point SHALL be considered inside of that contour. |
| O | The URI of the selected or default DGGS-JSON-FG profile SHALL be included in the links section of the JSON-FG response. |
| Identifier | /rec/data-dggs-jsonfg/profile-links |
|---|---|
| A | The implementation SHOULD return a link to the default or selected profile as a Link HTTP response header, for example Link: https://www.opengis.net/def/profile/ogc/0/jsonfg-dggs; rel="profile". |
| Identifier | /rec/data-dggs-jsonfg/geometry |
|---|---|
| A | The implementation SHOULD support a geometry query parameter allowing a client to choose how to return feature geometry. |
| B | The implementation SHOULD support a value of geometry=zone-centroid to request a representation where each feature is a zone intersecting the data, with the geometry of each feature being a Point geometry for the centroid of that zone. |
| C | The implementation SHOULD support a value of geometry=vectorized to request a representation where each feature corresponds to a feature of the data (sharing identical property values). |
| D | If a geometry value is not specified, the Implementation SHOULD return the representation closest to the native data. |
| E | If a requested geometry representation is not supported, the Implementation SHOULD return a 4xx HTTP error. |
16.5. Requirements Class “DGGS-UBJSON-FG Zone data encoding” (for geometry coordinates quantized to sub-zones)
16.5.1. Overview
The DGGS-UBJSON-FG Zone Data encoding requirements class defines support for encoding a DGGS Zone data response for vector features using the same JSON structure as the above DGGS-JSON-FG data requirements class, but using the binary UBJSON encoding.
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-dggs-ubjsonfg |
|---|---|
| Target type | Web API |
| Conformance class | Conformance class A.13: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-dggs-ubjsonfg |
| Prerequisites | https://ubjson.org/ Requirements class 2: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-retrieval https://www.opengis.net/spec/json-fg-1/0.3/req/core |
| Normative statement | Requirement 27: /req/data-dggs-ubjsonfg/content |
16.5.2. DGGS-UBJSON-FG Zone Data
| Identifier | /req/data-dggs-ubjsonfg/content |
|---|---|
| Included in | Requirements class 13: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-dggs-ubjsonfg |
| Statement | For encoding zone data as DGGS-UBJSON-FG |
| A | The Implementation SHALL support zone data requests negotiating an application/geo+ubjson media type combined with a profile query parameter with a value of jsonfg-dggs, jsonfg-dggs-plus, jsonfg-dggs-zoneids or jsonfg-dggs-zoneids-plus allowing a client to request a DGGS-UBJSON-FG response. |
| B | Every 200 response of the server for DGGS-UBJSON-FG zone data requests SHALL be a Universal Binary JSON document representing the vector features within the requested zone |
| C | The content of the UBJSON document SHALL follow all the of same requirements as for DGGS-JSON-FG described above. |
The py-ubjson tool can be used to easily convert between JSON and UBJSON. After installing with pip3 install py-ubjson, a DGGS-JSON-FG file can be converted to DGGS-UBJSON-FG with ubjson fromjson zoneData.dggsjsonfg, and a DGGS-UBJSON-FG file can be converted to DGGS-JSON-FG with ubjson tojson zoneData.dggsfg.ubj.
16.6. Requirements Class “GeoTIFF Zone data encoding”
16.6.1. Overview
The GeoTIFF Zone Data encoding requirements class defines support for encoding a DGGS Zone data response according to the OGC GeoTIFF standard.
GeoTIFF is a commonly used format for representing 2-dimensional gridded coverages.
For a DGGRS with non-rectangular zones (e.g., hexagonal zones), a GeoTIFF representation can be the minimal bounding rectangle of the zone shape, with NODATA values used outside the bounds of the zone.
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-geotiff |
|---|---|
| Target type | Web API |
| Conformance class | Conformance class A.14: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-geotiff |
| Prerequisites | TIFF V6.0 GeoTIFF Requirements class 2: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-retrieval |
| Normative statement | Requirement 28: /req/data-geotiff/content |
16.6.2. GeoTIFF Zone Data
| Identifier | /req/data-geotiff/content |
|---|---|
| Included in | Requirements class 14: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-geotiff |
| Statement | For encoding zone data as GeoTIFF |
| A | Every 200 response of the server for zone data with the media type image/tiff SHALL be a TIFF image representing the data values for all selected fields within the zone for which data is requested. |
| B | If the TIFF encoding incorporates a GeoTIFF georeference, this information SHALL be consistent with the DGGRS Zone ID. |
| C | If the zone geometry is not rectangular, the closest bounding rectangle SHALL be used for referencing the image. |
| D | A distinct value for each sub-zone implied from the requested zone-depth SHALL correspond to at least one distinct cell value in the response. |
| E | For Implementations supporting Data Custom Depths, each depth of the requested zone depth pyramid SHALL be a separate image (overview) in the response. |
| Identifier | /rec/data-geotiff/null-values |
|---|---|
| A | Null values SHOULD be used for cells lying outside the zone geometry. |
| Identifier | /rec/data-geotiff/crs |
|---|---|
| A | The CRS of the response SHOULD be consistent with either the DGGRS or the underlying geographic CRS (e.g., CRS84). |
16.7. Requirements Class “GeoJSON Zone data encoding”
16.7.1. Overview
The GeoJSON Zone Data encoding requirements class defines support for encoding a DGGS Zone data response according to the GeoJSON specification, and optionally according to the OGC JSON-FG candidate Standard.
GeoJSON is a commonly used format for representing features with simple geometries and related properties. GeoJSON is simple to understand and is well supported by tools and software libraries. Since most Web developers are comfortable with using JSON-based formats, supporting GeoJSON is recommended for a vector representation of DGGS Zone data.
JSON-FG is an OGC format for representing features with simple geometries and related properties extending GeoJSON for greater flexibility.
An Implementation may support JSON-FG representations in addition to GeoJSON as defined by RFC 7946.
A profile query parameter can be used by clients to request a particular GeoJSON / JSON-FG representation from Implementations supporting multiple options:
rfc7946: GeoJSON as defined by RFC 7946;
jsonfg: GeoJSON as extended by JSON-FG; and
jsonfg-plus: JSON-FG extensions in addition to GeoJSON compatibility (geometry specified in geometry limited to GeoJSON types, with coordinates either in OGC:CRS84 or in a CRS explicitly requested by the client using crs query parameter).
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-geojson |
|---|---|
| Target type | Web API |
| Conformance class | Conformance class A.15: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-geojson |
| Prerequisites | GeoJSON OGC 21-045r1 (optional JSON-FG dependency) Requirements class 2: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-retrieval |
| Normative statement | Requirement 29: /req/data-geojson/content |
16.7.2. GeoJSON Zone Data
| Identifier | /req/data-geojson/content |
|---|---|
| Included in | Requirements class 15: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-geojson |
| Statement | For encoding zone data as GeoJSON (and/or JSON-FG) |
| A | Every 200 response of the server for zone data with the media type application/geo+json SHALL be a GeoJSON document representing the features, including their geometry and associated properties, within the zone for which data is requested. |
| B | Unless otherwise specified by a prior arrangement (for example, an output crs query parameter) or by negotiating a JSON-FG profile, the coordinate reference system SHALL be CRS84(h) in longitude and latitude (and optional height above the WGS84 ellipsoid). |
| C | Features whose geometry lie wholly outside of the zone geometry SHALL NOT be included in the response. |
| D | If returning a JSON-FG profile, the profile URI SHALL be included in the links section of the JSON-FG response. |
| Identifier | /rec/data-geojson/jsonfg-profile |
|---|---|
| A | The Implementation SHOULD support a profile query parameter for zone data requests allowing to negotiate an OGC Feature & Geometry JSON representation, where a value of rfc7946 corresponds to RFC 7936 GeoJSON, a jsonfg value corresponds to a response conforming to JSON-FG, and a jsonfg-plus value corresponds to a response conforming to JSON-FG fully backward compatible with GeoJSON (e.g., including a GeoJSON geometry in the geometry field if geometry is otherwise provided in the JSON-FG-specific place property which supports extended geometry types and alternate coordinate reference system without prior agreement). |
| Identifier | /rec/data-geojson/profile-links |
|---|---|
| A | If returning a JSON-FG representation, the implementation SHOULD return a link to the default or selected profile as a Link HTTP response header, for example Link: https://www.opengis.net/def/profile/ogc/0/jsonfg; rel="profile". |
| Identifier | /rec/data-geojson/clipping |
|---|---|
| A | For features partially inside of the zone geometry, the geometry included in the response SHOULD be clipped to the boundaries of the zone geometry. |
| Identifier | /rec/data-geojson/generalization |
|---|---|
| A | The geometry of the features in the response SHOULD be generalized to the scale associated with the hierarchy level implied from the zone-depth relative to the requested zone. |
| Identifier | /rec/data-geojson/omission |
|---|---|
| A | For datasets whose features have either a size (such as areal or linear feature) or other properties making some features irrelevant at lower hierarchy levels, such irrelevant features SHOULD be omitted from the response based on the hierarchy level implied from the zone-depth relative to the requested zone. |
| Identifier | /rec/data-geojson/crs |
|---|---|
| A | For a JSON-FG response for which a crs query parameter is not specified, the CRS of the response SHOULD be consistent with the CRS of the DGGRS or the underlying geographic CRS (e.g., CRS84). |
| B | For a JSON-FG response for which a crs query parameter is specified, the geometry property SHOULD be used to return coordinates if the geometry does not require an extended JSON-FG type, since this constitutes a prior arrangement regarding the CRS of GeoJSON coordinates. |
| Identifier | /rec/data-geojson/geometry |
|---|---|
| A | The implementation SHOULD support a geometry query parameter allowing a client to choose how to return feature geometry. |
| B | The implementation SHOULD support a value of geometry=zone-centroid to request a representation where each feature is a zone intersecting the data, with the geometry of each feature being a Point geometry for the centroid of that zone. |
| C | The implementation SHOULD support a value of geometry=zone-region to request a representation where each feature is a zone intersecting the data, with the geometry of each feature being a (Multi)Polygon, (Multi)Polyhedron or (Multi)Prism. |
| D | The implementation SHOULD support a value of geometry=vectorized to request a representation where each feature corresponds to a feature of the data (sharing identical property values). |
| E | If a geometry value is not specified, the Implementation SHOULD return the representation closest to the native data. |
| F | If a requested geometry representation is not supported, the Implementation SHOULD return a 4xx HTTP error. |
16.8. Requirements Class “netCDF zone data encoding”
16.8.1. Overview
The netCDF Zone Data encoding requirements class defines support for encoding a DGGS Zone data response according to the OGC netCDF standard and to any encoding extension such as the NetCDF classic and 64-bit offset format, or netCDF version 4 based on OGC HDF5. NetCDF (network Common Data Form) is a data model for array-oriented scientific data, a freely distributed collection of access libraries implementing support for that data model, and machine-independent formats.
An Implementation may support either a DGGS-optimized netCDF representation where a dimension is associated with sub-zones, with coordinates being global zone identifiers or local indices into the deterministic zone order, or a traditional representation interoperable with non-DGGS clients where spatiotemporal axes are individual dimensions.
A profile query parameter can be used by clients to request a particular netCDF representation from Implementations supporting multiple options:
netcdf3: NetCDF classic and 64-bit offset format (not quantized to DGGH);
netcdf3-dggs: NetCDF classic and 64-bit offset format where one axis corresponds to local sub-zone indices;
netcdf3-dggs-zoneids: NetCDF classic and 64-bit offset format where one axis corresponds to the global identifiers of sub-zones (textual or 64-bit integer);
netcdf4: HFG5-based NetCDF 4 format (not quantized to DGGH);
netcdf4-dggs: HDF5-based NetCDF 4 format where one axis corresponds to local sub-zone indices; and
netcdf4-dggs-zoneids: HDF5-based NetCDF 4 format where one axis corresponds to the global identifiers of sub-zones (textual or 64-bit integer).
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-netcdf |
|---|---|
| Target type | Web API |
| Conformance class | Conformance class A.16: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-netcdf |
| Prerequisites | OGC Network Common Data Form (NetCDF) Core Encoding Standard version 1.0 Requirements class 2: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-retrieval |
| Normative statement | Requirement 30: /req/data-netcdf/content |
16.8.2. NetCDF Zone Data
| Identifier | /req/data-netcdf/content |
|---|---|
| Included in | Requirements class 16: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-netcdf |
| Statement | For encoding zone data as netCDF |
| A | Every 200 response of the server for zone data with the media type application/netcdf SHALL be a netCDF file representing the data values for all selected fields of each included sub-zone. |
| B | The response SHALL be encoded using a netCDF encoding extension, such as the NetCDF classic and 64-bit offset format, or netCDF version 4 based on OGC HDF5. |
| C | For a DGGS-optimized profile (netcdf3-dggs, netcdf3-dggs-zoneids, netcdf4-dggs, netcdf3-dggs-zoneids), the profile URI, the global identifier of the parent zone and a URI or link to the DGGRS definition SHALL be included as metadata. |
| D | For a DGGS-optimized profile, coordinates along one dimension SHALL correspond to sub-zones, either as global zone identifiers (netcdf3-dggs-zoneids, netcdf4-dggs-zoneids) or local sub-zone indices following the deterministic DGGRS sub-zone order (netcdf3-dggs, netcdf4-dggs), while spatiotemporal dimensions of the DGGRS SHALL NOT be defined as separate dimensions. |
| E | For non-DGGS-optimized profiles, if the netCDF data incorporates georeferencing information, this information SHALL be consistent with the DGGRS Zone ID. |
| F | For non-DGGS-optimized profiles, if the zone geometry is not rectilinear, the closest bounding rectangle (or volume) SHALL be used for referencing the data. |
| G | For non-DGGS-optimized profiles, a distinct value for each sub-zone implied from the requested zone-depth SHALL correspond to at least one distinct cell value in the response. |
| Identifier | /rec/data-netcdf/null-values |
|---|---|
| A | For non-DGGS-optimized profiles, null values SHOULD be used for cells lying outside the zone geometry. |
| Identifier | /rec/data-netcdf/crs |
|---|---|
| A | For non-DGGS-optimized profiles, the spatial reference of the response, determined by the units of the coordinate variables and whether or not the grid_mapping attribute exists, as well as any applicable extension in use such as CF-netCDF, SHOULD be consistent with either the DGGRS or the underlying geographic CRS (e.g., CRS84). |
| Identifier | /rec/data-netcdf/profile |
|---|---|
| A | The Implementation SHOULD support a profile query parameter for zone data requests allowing to negotiate a particular representation, including the selection of classic netCDF 3 and 64-bit offset format (netcdf3, netcdf3-dggs or netcdf3-dggs-zoneids) or netCDF 4 based on OGC HDF5 (netcdf4, netcdf4-dggs or netcdf4-dggs-zoneids), as well as the selection of a dimension representing global sub-zone identifiers (netcdf3-dggs-zoneids or netcdf4-dggs-zoneids) or local sub-zone indices based on the deterministic order as defined by the DGGRS (netcdf3-dggs or netcdf4-dggs), or individual spatiotemporal dimensions for interoperability with non-DGGS clients (netcdf3 or netcdf4). |
| Identifier | /rec/data-netcdf/profile-links |
|---|---|
| A | The implementation SHOULD return a link to the default or selected profile as a Link HTTP response header, for example Link: https://www.opengis.net/def/profile/ogc/0/netcdf4-dggs; rel="profile". |
16.9. Requirements Class “Zarr zone data encoding”
16.9.1. Overview
The Zarr Zone Data encoding requirements class defines support for encoding a DGGS Zone data response according to the OGC Zarr Storage Specification 2.0 Community Standard, packed into a Zip archive.
An Implementation may support either a DGGS-optimized Zarr representation where a dimension is associated with sub-zones, with coordinates being global zone identifiers or local indices into the deterministic zone order, or a traditional representation interoperable with non-DGGS clients where spatiotemporal axes are individual dimensions.
A profile query parameter can be used by clients to request a particular Zarr representation from Implementations supporting multiple options:
zarr2: Zipped Zarr 2.0 (not quantized to DGGH);
zarr2-dggs: Zipped Zarr 2.0 where one axis corresponds to local sub-zone indices; and
zarr2-dggs-zoneids: Zipped Zarr 2.0 where one axis corresponds to the global identifiers of sub-zones (textual or 64-bit integer).
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-zarr |
|---|---|
| Target type | Web API |
| Conformance class | Conformance class A.17: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-zarr |
| Prerequisites | OGC Zarr Storage Specification 2.0 Community Standard ISO/IEC 21320-1:2015 Information technology — Document Container File (Zip) Requirements class 2: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-retrieval |
| Normative statement | Requirement 31: /req/data-zarr/content |
16.9.2. Zarr Zone Data
| Identifier | /req/data-zarr/content |
|---|---|
| Included in | Requirements class 17: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-zarr |
| Statement | For encoding zone data as zipped Zarr 2 |
| A | Every 200 response of the server for zone data with the media type application/zarr+zip SHALL be a Zip file containing the data values for all selected fields of each included sub-zone encoded following the Zarr Storage Specification Version 2 file. |
| B | For a DGGS-optimized profile (zarr2-dggs, zarr2-dggs-zoneids), the profile URI, the global identifier of the parent zone and a URI or link to the DGGRS definition SHALL be included as metadata. |
| C | For a DGGS-optimized profile, coordinates along one dimension SHALL correspond to sub-zones, either as global zone identifiers (zarr2-dggs-zoneids) or local sub-zone indices following the deterministic DGGRS sub-zone order (zarr2-dggs), while spatiotemporal dimensions of the DGGRS SHALL NOT be defined as separate dimensions. |
| D | For a DGGS-optimized profile, at every depth, each individual value SHALL correspond exactly to the data sampled representative of that sub-zone. |
| E | For non-DGGS-optimized profiles, if the Zarr data incorporates georeferencing information (such as defined by the candidate OGC GeoZarr Standard), this information SHALL be consistent with the DGGRS Zone ID. |
| F | For non-DGGS-optimized profiles, if the zone geometry is not rectilinear, the closest bounding rectangle (or volume) SHALL be used for referencing the data. |
| G | For non-DGGS-optimized profiles, a distinct value for each sub-zone implied from the requested zone-depth SHALL correspond to at least one distinct cell value in the response. |
| H | If multiple relative zone depths are being returned, each depth SHALL be encoded as a separate Zarr dataset within the data packet. |
| I | Every zone depth requested using the zone-depth query parameter SHALL be included in the response. |
| Identifier | /rec/data-zarr/no-extra-chunking |
|---|---|
| A | Since the zone data packet are for a limited set of sub-zones within a single parent zone, the zone data response SHOULD be encoded as a single chunk. |
| Identifier | /rec/data-zarr/null-values |
|---|---|
| A | For non-DGGS-optimized profiles, null values SHOULD be used for cells lying outside the zone geometry. |
| Identifier | /rec/data-zarr/crs |
|---|---|
| A | For non-DGGS-optimized profiles, if the response contains georeferencing information (such as defined by the candidate OGC GeoZarr Standard) the spatial reference of the response SHOULD be consistent with either the DGGRS or the underlying geographic CRS (e.g., CRS84). |
| Identifier | /rec/data-zarr/profile |
|---|---|
| A | The Implementation SHOULD support a profile query parameter for zone data requests allowing to negotiate a particular representation, including the selection of a dimension representing global sub-zone identifiers (zarr-dggs-zoneids) or local sub-zone indices based on the deterministic order as defined by the DGGRS (zarr2-dggs), or individual spatiotemporal dimensions for interoperability with non-DGGS clients (zarr2). |
| Identifier | /rec/data-zarr/profile-links |
|---|---|
| A | The implementation SHOULD return a link to the default or selected profile as a Link HTTP response header, for example Link: https://www.opengis.net/def/profile/ogc/0/zarr2-dggs; rel="profile". |
16.10. Requirements Class “CoverageJSON zone data encoding”
16.10.1. Overview
The CoverageJSON requirements class defines support for encoding a DGGS Zone data response according to the OGC CoverageJSON Community Standard.
An Implementation may support either a DGGS-optimized CoverageJSON representation where a dimension is associated with sub-zones, with coordinates being global zone identifiers or local indices into the deterministic zone order, or a traditional representation interoperable with non-DGGS clients where spatiotemporal axes are individual dimensions.
A profile query parameter can be used by clients to request a particular CoverageJSON representation from Implementations supporting multiple options:
covjson: CoverageJSON (not quantized to DGGH);
covjson-dggs: CoverageJSON where one axis corresponds to local sub-zone indices; and
covjson-dggs-zoneids: CoverageJSON where one axis corresponds to the global identifiers of sub-zones (textual or 64-bit integer).
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-coveragejson |
|---|---|
| Target type | Web API |
| Conformance class | Conformance class A.18: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-coveragejson |
| Prerequisites | OGC 21-069r2 Requirements class 2: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-retrieval |
| Normative statement | Requirement 32: /req/data-coveragejson/content |
16.10.2. CoverageJSON Zone Data
| Identifier | /req/data-coveragejson/content |
|---|---|
| Included in | Requirements class 18: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-coveragejson |
| Statement | For encoding zone data as CoverageJSON |
| A | Every 200 response of the server for zone data with the media type application/prs.coverage+json SHALL be a CoverageJSON file representing the data values for all selected fields of each included sub-zone. |
| B | For a DGGS-optimized profile (covjson-dggs, covjson-dggs-zoneids), the profile URI, the global identifier of the parent zone and a URI or link to the DGGRS definition SHALL be included as metadata. |
| C | For a DGGS-optimized profile, coordinates along one dimension SHALL correspond to sub-zones, either as global zone identifiers (covjson-dggs-zoneids) or local sub-zone indices following the deterministic DGGRS sub-zone order (covjson-dggs), while spatiotemporal dimensions of the DGGRS SHALL NOT be defined as separate dimensions. |
| D | For non-DGGS-optimized profiles, if the CoverageJSON encoding incorporates georeferencing information, this information SHALL be consistent with the DGGRS Zone ID. |
| E | For non-DGGS-optimized profiles, if the zone geometry is not rectilinear, the closest bounding rectangle (or volume) SHALL be used for referencing the data. |
| F | For non-DGGS-optimized profiles, a distinct value for each sub-zone implied from the requested zone-depth SHALL correspond to at least one distinct cell value in the response. |
| Identifier | /rec/data-coveragejson/null-values |
|---|---|
| A | For non-DGGS-optimized profiles, null values SHOULD be used for cells lying outside the zone geometry. |
| Identifier | /rec/data-coveragejson/crs |
|---|---|
| A | For non-DGGS-optimized profiles, the CRS of the response SHOULD be consistent with either the DGGRS or the underlying geographic CRS (e.g., CRS84). |
| Identifier | /rec/data-coveragejson/profile |
|---|---|
| A | The Implementation SHOULD support a profile query parameter for zone data requests allowing to negotiate a particular representation, including the selection of a dimension representing global sub-zone identifiers (covjson-dggs-zoneids) or local sub-zone indices based on the deterministic order as defined by the DGGRS (covjson-dggs), or individual spatiotemporal dimensions for interoperability with non-DGGS clients (covjson). |
| Identifier | /rec/data-coveragejson/profile-links |
|---|---|
| A | The implementation SHOULD return a link to the default or selected profile as a Link HTTP response header, for example Link: https://www.opengis.net/def/profile/ogc/0/covjson-dggs; rel="profile". |
16.11. Requirements Class “JPEG-XL Zone data encoding”
16.11.1. Overview
The JPEG XL Zone Data encoding requirements class defines support for encoding a DGGS Zone data response according to the JPEG XL ISO/IEC 18181 Standard.
JPEG XL supports a large number of bands, image dimensions, and floating point values.
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-jpegxl |
|---|---|
| Target type | Web API |
| Conformance class | Conformance class A.19: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-jpegxl |
| Prerequisites | ISO/IEC 18181-1 ISO/IEC 18181-2 Requirements class 2: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-retrieval |
| Normative statement | Requirement 33: /req/data-jpegxl/content |
16.11.2. JPEG XL Zone Data
| Identifier | /req/data-jpegxl/content |
|---|---|
| Included in | Requirements class 19: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-jpegxl |
| Statement | For encoding zone data as JPEG XL |
| A | Every 200 response of the server for zone data with the media type image/jxl SHALL be a JPEG XL image representing the data values for all selected fields within the zone for which data is requested. |
| B | If the zone geometry is not rectangular, the closest bounding rectangle SHALL be used for referencing the image. |
| C | A distinct value for each sub-zone implied from the requested zone-depth SHALL correspond to at least one distinct cell value in the response. |
| D | For Implementations supporting Data Custom Depths, each depth of the requested zone depth pyramid SHALL be a separate image (overview) in the response. |
| Identifier | /rec/data-jpegxl/null-values |
|---|---|
| A | Null values SHOULD be used for cells lying outside the zone geometry. |
| Identifier | /rec/data-jpegxl/crs |
|---|---|
| A | The CRS of the response SHOULD be consistent with either the DGGRS or the underlying geographic CRS (e.g., CRS84). |
16.12. Requirements Class “PNG Zone data encoding”
16.12.1. Overview
The PNG Zone Data encoding requirements class defines support for encoding a DGGS Zone data response according to the W3C Portable Network Graphics (PNG) Specification (ISO/IEC 15948:2003).
Because PNG encoding is limited to integer data values, this requirements class defines additional query parameters and response headers allowing a client to request a specific scale factor and offset to be used to quantize data values, and allowing the implementation to inform the client of the scale factor and offset used for that quantization.
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-png |
|---|---|
| Target type | Web API |
| Conformance class | Conformance class A.20: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-png |
| Prerequisites | ISO/IEC 15948 Requirements class 2: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-retrieval |
| Normative statement | Requirement 34: /req/data-png/content |
16.12.2. PNG Zone Data
| Identifier | /req/data-png/content |
|---|---|
| Included in | Requirements class 20: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-png |
| Statement | For encoding zone data as PNG |
| A | Every 200 response of the server for zone data with the media type image/png SHALL be a PNG image representing the data values for all selected fields within the zone for which data is requested. |
| B | If the zone geometry is not rectangular, the closest bounding rectangle SHALL be used for referencing the image. |
| C | A distinct value for each sub-zone implied from the requested zone-depth SHALL correspond to at least one distinct cell value in the response. |
| D | For Implementations supporting Data Custom Depths, request for multiple depths SHALL result in a 4xx error (since the PNG format does not support image pyramids / overview). |
| E | A Values-Scale: response header with a numeric real value SHALL be returned indicating the factor by which values were multiplied before an offset was added to result in the encoded 8-bit or 16-bit PNG unsigned integer values. |
| F | A Values-Offset: response header with a numeric real value SHALL be returned indicating the offset which was added after multiplying values by the scale factor to result in the encoded 8-bit or 16-bit PNG unsigned integer values. |
| Identifier | /rec/data-png/null-values |
|---|---|
| A | Null values SHOULD be used for cells lying outside the zone geometry. |
| Identifier | /rec/data-png/crs |
|---|---|
| A | The CRS of the response SHOULD be consistent with either the DGGRS or the underlying geographic CRS (e.g., CRS84). |
| Identifier | /rec/data-png/scale-offset |
|---|---|
| A | The Implementation SHOULD support a values-scale query parameter on Zone data resources when requesting a PNG output to indicate the value scale factor, as described in the Values-Scale response header part of the content requirement. |
| B | The Implementation SHOULD support a values-offset query parameter on Zone data resources when requesting a PNG output to indicate the value offset, as described in the Values-Offset response header part of the content requirement. |
17. Requirements Classes for Encodings of Zone list
The OGC API — DGGS Standard requires supporting a JSON encoding for returning the ../dggs/{dggrsId}/zones resources, as described in the Zone Query requirement class. In addition to this JSON encoding, DGGRS Zone Lists can be encoded in any suitable data format, as negotiated by server and client. A number of requirements classes are defined for zone list encodings which are expected to be commonly supported in implementations of this Standard. These requirements classes include:
GeoJSON Zone List — including support for Features & Geometry JSON (JSON-FG) output as a recommendation
17.1. Media Types (for zone list)
A table of the media types used in the zone list encoding requirements classes defined in this standard follows.
Table 4 — Media Types used for zone list encoding requirements classes
| Encoding | Media type |
| JSON zone list | application/json |
| HTML zone list | text/html |
| Binary 64-bit zone list | application/x-binary |
| GeoJSON / JSON-FG zone list | application/geo+json |
| GeoTIFF zone list | image/tiff; application=geotiff |
17.2. Requirements Class “HTML zone list encoding”
17.2.1. Overview
The HTML zone list encoding requirements class defines at a high level the ability to retrieve an HTML response for the DGGRS zone list resource intended primarily for users accessing the API from a Web browser.
The exact content of the HTML response is not prescribed, leaving the flexibility for implementations to choose a preferred approach.
HTML is the core language of the World Wide Web. An API that supports HTML will support browsing the spatial resources with a web browser and will also enable search engines to crawl and index those resources.
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-html |
|---|---|
| Target type | Web API |
| Conformance class | Conformance class A.21: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/zone-html |
| Prerequisites | https://html.spec.whatwg.org/: Requirements class 6: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-query |
| Normative statement | Requirement 35: /req/zone-html/content |
17.2.2. HTML Zone List
| Identifier | /req/zone-html/content |
|---|---|
| Included in | Requirements class 21: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-html |
| Statement | For returning zone lists encoded as HTML: |
| A | Every 200 response of the server for zone query with the media type text/html SHALL be an HTML document listing the textual identifiers for all zones matching the query. |
| Identifier | /rec/zone-html/zone-information |
|---|---|
| A | The implementation SHOULD include additional information for each zone ID, such as the area, bounding box and/or a preview of the data available for this zone. |
| Identifier | /rec/zone-html/zone-data |
|---|---|
| A | If the Implementation also supports Zone Data Retrieval, the Implementation SHOULD include a link for each zone to download the associated data . |
17.3. Requirements Class “Binary 64-bit integer zone list encoding”
17.3.1. Overview
The binary 64-bit integer zone list encoding requirements class defines the ability to retrieve a binary response for the DGGRS zone list resource for DGGRS whose zone identifiers can be expressed as a single 64-bit integer.
The response consists of a 64-bit integer count of zones, followed by that count of zones, also 64-bit integers. With compact zones and additional HTTP content encoding compression, this provides an optimal way to exchange DGGRS zone lists.
Requirements class 22: Requirements Class 64-bit Binary Zone List | |
|---|---|
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-uint64 |
| Target type | Web API |
| Conformance class | Conformance class A.22: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/zone-uint64 |
| Prerequisite | Requirements class 6: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-query |
| Normative statement | Requirement 36: /req/zone-uint64/content |
17.3.2. 64 bit Binary Zone List
| Identifier | /req/zone-uint64/content |
|---|---|
| Included in | Requirements class 22: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-uint64 |
| Statement | For returning zone lists encoded as binary 64-bit unsigned integers: |
| A | Every 200 response of the server for zone query with the media type application/x-binary SHALL be a binary response consisting of a first 64-bit integer count defining the number of zones returned, followed by one 64-bit integer for each zone matching the query. |
| B | The 64-bit integer identifiers SHALL be the ones defined by the DGGRS. |
| C | The endianness of the returned count and zones integers SHALL be little endian. |
| D | If the DGGRS does not define a 64-bit integer identifier, a 406 “Not Acceptable” response SHALL be returned. |
17.4. Requirements Class “GeoJSON zone list encoding”
17.4.1. Overview
The GeoJSON zone list encoding requirements class defines support for encoding a DGGRS Zone list response according to the GeoJSON specification, and optionally according to the OGC Features & Geometry JSON (JSON-FG) Standard.
The response is a feature collection where each feature represents a zone in the list. The geometry of the zone should be polygons or multipolygons (e.g., in the case of zone geometry which must be split on the anti-meridian or pole), or in the case of a 3D DGGRS and a JSON-FG response polyhedrons, multipolyhedrons, prisms, or multiprisms. The zone identifier is represented in the id field of each feature.
While not intended to efficiently exchange zone list, as the response carries the geometry of the zones which could easily be computed client-side which takes considerable bandwidth and is not necessary for a DGGS client working natively with the same DGGRS, this requirements class provides an easy way to readily visualize the response in a variety of tools. This requirements class is therefore intended for convenience, demonstration and educational purposes.
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-geojson |
|---|---|
| Target type | Web API |
| Conformance class | Conformance class A.23: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/zone-geojson |
| Prerequisites | GeoJSON OGC 21-045r1 (optional JSON-FG dependency) Requirements class 6: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-query |
| Normative statement | Requirement 37: /req/zone-geojson/content |
17.4.2. GeoJSON Zone List
| Identifier | /req/zone-geojson/content |
|---|---|
| Included in | Requirements class 23: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-geojson |
| Statement | For returning zone lists encoded as GeoJSON: |
| A | Every 200 response of the server for zone query with the media type application/geo+json SHALL be a GeoJSON document consisting of a FeatureCollection, where every Feature represents a single zone. |
| B | Unless otherwise specified by a prior arrangement (for example, an output crs query parameter) or by negotiating a JSON-FG profile, the coordinate reference system SHALL be CRS84(h) in longitude and latitude (and optional height above the WGS84 ellipsoid). |
| C | Every feature SHALL have a zoneID property corresponding to the textual identifier of the zone. |
| D | The geometry of each feature SHALL be the geometry of the zone. |
| E | If returning a JSON-FG profile, the profile URI SHALL be included in the links section of the JSON-FG response. |
| Identifier | /rec/zone-geojson/jsonfg-profile |
|---|---|
| A | The Implementation SHOULD support a profile query parameter for zone query requests allowing to negotiate an OGC Feature & Geometry JSON representation, where a value of rfc7946 corresponds to RFC 7936 GeoJSON, a jsonfg value corresponds to a response conforming to JSON-FG, and a jsonfg-plus value corresponds to a response conforming to JSON-FG fully backward compatible with GeoJSON (e.g., including a GeoJSON geometry in the geometry field if geometry is otherwise provided in the JSON-FG-specific place property which supports extended geometry types and alternate coordinate reference system without prior agreement). |
| Identifier | /rec/zone-geojson/profile-links |
|---|---|
| A | If returning a JSON-FG representation, the implementation SHOULD also return a link to the default or selected profile as a Link HTTP response header, for example Link: https://www.opengis.net/def/profile/ogc/0/jsonfg; rel="profile". |
| Identifier | /rec/zone-geojson/id |
|---|---|
| A | The Feature id SHOULD be a sequential identifier starting at 1, have the same text value as the zoneID property, or correspond to the 64-bit integer identifier for the zone. |
| Identifier | /rec/zone-geojson/crs |
|---|---|
| A | For a JSON-FG response for which a crs query parameter is not specified, the CRS of the response SHOULD be consistent with the CRS of the DGGRS or the underlying geographic CRS (e.g., CRS84). |
| B | For a JSON-FG response for which a crs query parameter is specified, the geometry property SHOULD be used to return coordinates if the geometry does not require an extended JSON-FG type, since this constitutes a prior arrangement regarding the CRS of GeoJSON coordinates. |
| Identifier | /rec/zone-geojson/mid-points |
|---|---|
| A | For DGGRSs not in CRS84, the geometry SHOULD include intermediate points between the vertices of the zone geometry so as to accurately represent the shape of the zones. |
| Identifier | /rec/zone-geojson/geometry |
|---|---|
| A | The implementation SHOULD support a geometry query parameter allowing a client to choose how to return the geometry of each zone. |
| B | The implementation SHOULD support a value of geometry=zone-centroid to request a representation where the geometry of each a zone is a Point geometry for the centroid of that zone. |
| C | The implementation SHOULD support a value of geometry=zone-region to request a representation where the geometry of each zone is a (Multi)Polygon, (Multi)Polyhedron, or (Multi)Prism. |
| D | The implementation SHOULD support a value of geometry=none to request a representation with a null geometry. |
| E | If a requested geometry representation is not supported, the Implementation SHOULD return a 4xx HTTP error. |
17.5. Requirements Class “GeoTIFF zone list encoding”
17.5.1. Overview
The GeoTIFF zone list encoding requirements class defines support for encoding a DGGRS Zone list response according to the OGC GeoTIFF standard, intended primarily for DGGRSs with rectangular zones.
The response is a 2D gridded coverage where each cell is a zone in the list, in the coordinate reference system of that DGGRS.
For DGGRSs with non-rectangular zones, the resolution would need to be higher than a single pixel per the most detailed zone to be returned in order to be able to recognize the zone geometry, and would therefore be very sub-optimal. While for rectangular zones it would be easy to identify zones with a one-to-one correspondence, recognizing non-rectangular zones would be significantly more difficult.
While not intended to efficiently exchange zone list, this requirements class provides an easy way to readily visualize the response in a variety of tools. This requirements class is therefore intended for convenience, demonstration and educational purposes.
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-geotiff |
|---|---|
| Target type | Web API |
| Conformance class | Conformance class A.24: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/zone-geotiff |
| Prerequisites | TIFF V6.0 GeoTIFF Requirements class 6: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-query |
| Normative statement | Requirement 38: /req/zone-geotiff/content |
17.5.2. GeoTIFF Zone List
| Identifier | /req/zone-geotiff/content |
|---|---|
| Included in | Requirements class 24: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-geotiff |
| Statement | For returning zone lists encoded as GeoTIFF: |
| A | Every 200 response of the server for zone query with the media type image/tiff SHALL be a GeoTIFF document representing the zones matching the query in a geo-referenced image where each zone corresponds to at least one pixel. |
| B | The GeoTIFF SHALL be encoded as Pixel-Is-Area. |
| Identifier | /rec/zone-geotiff/crs |
|---|---|
| A | The CRS of the response SHOULD be consistent with either the DGGRS or the underlying geographic CRS (e.g., CRS84). |
| Identifier | /rec/zone-geotiff/values |
|---|---|
| A | The value of the pixel SHOULD be a 64-bit integer identifier representing the zone, if the DGGRS provides for such an identifier. |
| Identifier | /rec/zone-geotiff/non-rectilinear |
|---|---|
| A | For DGGRS where the zones do not correspond to a rectilinear structure, the resolution of the response image SHOULD be high enough so that the shape of the zone geometry is recognizable. |
18. Requirements Class “API definition Operation IDs”
The OGC API — DGGS Standard does not mandate any particular API definition language. However, if the API is described using a definition language supporting operation identifiers, such as OpenAPI 3.0, being able to associate the functionality described in these requirements with an operation defined in the language is useful. This requirements class defines how this is achieved.
18.1. Overview
Requirements class 25: Requirements Class API Definition Operation IDs | |
|---|---|
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/operation-ids |
| Target type | Web API |
| Conformance class | Conformance class A.25: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/operation-ids |
| Prerequisite | https://www.opengis.net/spec/ogcapi-common-1/1.0/req/landing-page |
| Normative statement | Requirement 39: /req/operation-ids/operation-ids |
18.2. Operation IDs
| Identifier | /req/operation-ids/operation-ids |
|---|---|
| Included in | Requirements class 25: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/operation-ids |
| Statement | For specifying the operation identifiers associated with the capabilities defined in OGC API — DGGS |
| A | The API definition SHALL identify the supported operations defined in this Standard using the identifier suffixes defined in Table 5. |
Table 5 — API operation identifier suffixes
| Origin | Resource | Operation id suffixes |
|---|---|---|
| With the origins described in this document | ||
| DataSet4 | DGGRS List1 | .dataset.getDGGRSList |
| DataSet4 | DGGRS Description1 | .dataset.getDGGRS |
| DataSet4 | DGGRS Zones2 | .dataset.getDGGRSZones |
| DataSet4 | DGGRS Zone Information1 | .dataset.getDGGRSZoneInfo |
| DataSet4 | DGGRS Zone Data3 | .dataset.getDGGRSZoneData |
| Collection5 | DGGRS List1 | .collection.getDGGRSList |
| Collection5 | DGGRS Description1 | .collection.getDGGRS |
| Collection5 | DGGRS Zones2 | .collection.getDGGRSZones |
| Collection5 | DGGRS Zone Information1 | .collection.getDGGRSZoneInfo |
| Collection5 | DGGRS Zone Data3 | .collection.getDGGRSZoneData |
| With other potential origins6 | ||
| other | DGGRS List1 | #.getDGGRSList |
| other | DGGRS Description1 | #.getDGGRS |
| other | DGGRS Zones2 | #.getDGGRSZones |
| other | DGGRS Zone Information1 | #.getDGGRSZoneInfo |
| other | DGGRS Zone Data3 | #.getDGGRSZoneData |
| 1 The DGGRS List (…/dggs), DGGRS Description (…/dggs/{dggrsId}) and DGGRS Zone Information (…/dggs/{dggrsId}/zones/{zoneId}) resources are defined in requirements class “Core”. | ||
| 2 The DGGRS Zones resource (…/dggs/{dggrsId}/zones) is defined in the “Zone Query” requirements class. | ||
| 3 The DGGRS Zone Data resource (…/dggs/{dggrsId}/zones/{zoneId}/data) is defined in the “Data Retrieval” requirements class. | ||
| 4 The DataSet origin is defined in requirements class “Root DGGS” and depends on OGC API — Common — Part 1: Core. | ||
| 5 The Collection origin is defined in requirements class “Collection DGGS” and depends on the Collections requirements class defined in OGC API — Common — Part 2: Geospatial data. | ||
| 6 ‘#’ represents an optional origin that could be defined in another relevant standard. | ||
Annex A
(normative)
Conformance Class Abstract Test Suite
A.1. Conformance Class “Core”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/core |
|---|---|
| Requirements class | Requirements class 1: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/core |
| Target Type | Web API |
| Conformance tests | Abstract test A.1: /conf/core/dggrs-list Abstract test A.2: /conf/core/dggrs-description Abstract test A.3: /conf/core/zone-info |
A.1.1. Abstract Test for Requirement Listing available DGGRS
| Identifier | /conf/core/dggrs-list |
|---|---|
| Requirement | Requirement 1: /req/core/dggrs-list |
| Test purpose | Verify that the Implementation supports listing the available DGGRSs |
| Test method | Given: a geospatial data resource conforming to the DGGS API Standard, with an API path including …/dggs or discovered following a link with relation type [ogc-rel:dggrs-list] |
A.1.2. Abstract Test for Requirement Discrete global grid reference system description
| Identifier | /conf/core/dggrs-description |
|---|---|
| Requirement | Requirement 2: /req/core/dggrs-description |
| Test purpose | Verify that the Implementation supports retrieving information for a particular DGGRS |
| Test method | Given: a DGGRS resource identified from listing available DGGRS or discovered by following a link with relation type [ogc-rel:dggrs] |
A.1.3. Abstract Test for Requirement Retrieving zone information
| Identifier | /conf/core/zone-info |
|---|---|
| Requirement | Requirement 3: /req/core/zone-info |
| Test purpose | Verify that the Implementation supports retrieving information for a particular DGGRS zone |
| Test method | Given: a DGGRS zone information resource identified from a [ogc-rel:dggrs-zone-info] link template within a DGGRS description resource, replacing the {zoneId} variable with a known valid identifier for the DGGRS, not beyond the maxRefinementLevel if one is specified |
A.2. Conformance Class “Data Retrieval”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-retrieval |
|---|---|
| Requirements class | Requirements class 2: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-retrieval |
| Target Type | Web API |
| Conformance test | Abstract test A.4: /conf/data-retrieval/zone-data |
A.2.1. Abstract Test for Requirement Retrieving data from a zone
| Identifier | /conf/data-retrieval/zone-data |
|---|---|
| Requirement | Requirement 4: /req/data-retrieval/zone-data |
| Test purpose | Verify that the Implementation supports retrieving data for a particular DGGRS zone |
| Test method | Given: a DGGRS zone data resource identified from a [ogc-rel:dggrs-zone-data] link template within a DGGRS description resource, replacing the {zoneId} variable with a known valid identifier for the DGGRS, not beyond the maxRefinementLevel if one is specified |
A.3. Conformance Class “Data Subsetting”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-subsetting |
|---|---|
| Requirements class | Requirements class 3: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-subsetting |
| Target Type | Web API |
| Conformance tests | Abstract test A.5: /conf/data-subsetting/subset Abstract test A.6: /conf/data-subsetting/datetime Abstract test A.7: /conf/data-subsetting/properties Abstract test A.8: /conf/data-subsetting/exclude-properties |
A.3.1. Abstract Test for Requirement subset query parameter
| Identifier | /conf/data-subsetting/subset |
|---|---|
| Requirement | Requirement 5: /req/data-subsetting/subset |
| Test purpose | Verify that the Implementation supports specifying a multi-dimensional subset for the zone data being retrieved |
| Test method | Given: a DGGRS zone data resource identified from a [ogc-rel:dggrs-zone-data] link template within a DGGRS description resource, replacing the {zoneId} variable with a known valid identifier for the DGGRS which successfully passed the /conf/data-retrieval abstract test |
A.3.2. Abstract Test for Requirement datetime query parameter
| Identifier | /conf/data-subsetting/datetime |
|---|---|
| Requirement | Requirement 6: /req/data-subsetting/datetime |
| Test purpose | Verify that the Implementation supports specifying a time instant or interval for which to retrieve data from a zone for a non-temporal DGGS |
| Test method | Given: a DGGRS zone data resource identified from a [ogc-rel:dggrs-zone-data] link template within a DGGRS description resource, replacing the {zoneId} variable with a known valid identifier for the DGGRS which successfully passed the /conf/data-retrieval abstract test |
A.3.3. Abstract Test for Requirement properties query parameter
| Identifier | /conf/data-subsetting/properties |
|---|---|
| Requirement | Requirement 7: /req/data-subsetting/properties |
| Test purpose | Verify that the Implementation supports specifying fields to include when retrieving zone data |
| Test method | Given: a DGGRS zone data resource identified from a [ogc-rel:dggrs-zone-data] link template within a DGGRS description resource, replacing the {zoneId} variable with a known valid identifier for the DGGRS which successfully passed the /conf/data-retrieval abstract test |
A.3.4. Abstract Test for Requirement exclude-properties query parameter
| Identifier | /conf/data-subsetting/exclude-properties |
|---|---|
| Requirement | Requirement 8: /req/data-subsetting/exclude-properties |
| Test purpose | Verify that the Implementation supports including all but specific fields when retrieving zone data |
| Test method | Given: a DGGRS zone data resource identified from a [ogc-rel:dggrs-zone-data] link template within a DGGRS description resource, replacing the {zoneId} variable with a known valid identifier for the DGGRS which successfully passed the /conf/data-retrieval abstract test |
A.4. Conformance Class “Data Custom Depths”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-custom-depths |
|---|---|
| Requirements class | Requirements class 4: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-custom-depths |
| Target Type | Web API |
| Conformance test | Abstract test A.9: /conf/data-custom-depths/zone-depth |
A.4.1. Abstract Test for Requirement zone-depth query parameter
| Identifier | /conf/data-custom-depths/zone-depth |
|---|---|
| Requirement | Requirement 9: /req/data-custom-depths/zone-depth |
| Test purpose | Verify that the Implementation supports a query parameter to specify the DGGS refinement levels beyond the specified DGGS zone’s refinement level to include in the response, when retrieving data for that zone |
| Test method | Given: a DGGRS zone data resource identified from a [ogc-rel:dggrs-zone-data] link template within a DGGRS description resource, replacing the {zoneId} variable with a known valid identifier for the DGGRS which successfully passed the /conf/data-retrieval abstract test |
A.5. Conformance Class “Filtering Zone Data with CQL2”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-cql2-filter |
|---|---|
| Requirements class | Requirements class 5: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-cql2-filter |
| Target Type | Web API |
| Conformance test | Abstract test A.10: /conf/data-cql2-filter/filter |
A.5.1. Abstract Test for Requirement filter query parameter (for zone data)
| Identifier | /conf/data-cql2-filter/filter |
|---|---|
| Requirement | Requirement 10: /req/data-cql2-filter/filter |
| Test purpose | Verify that the Implementation supports specifying a CQL2 expression filtering the data returned from a zone data request |
| Test method | Given: a DGGRS zone data resource identified from a [ogc-rel:dggrs-zone-data] link template within a DGGRS description resource, replacing the {zoneId} variable with a known valid identifier for the DGGRS which successfully passed the /conf/data-retrieval abstract test |
A.6. Conformance Class “Zone Query”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/zone-query |
|---|---|
| Requirements class | Requirements class 6: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-query |
| Target Type | Web API |
| Conformance tests | Abstract test A.11: /conf/zone-query/zones-list Abstract test A.12: /conf/zone-query/json-response Abstract test A.13: /conf/zone-query/zone-level Abstract test A.14: /conf/zone-query/compact-zones Abstract test A.15: /conf/zone-query/parent-zone Abstract test A.16: /conf/zone-query/bbox Abstract test A.17: /conf/zone-query/bbox-crs Abstract test A.18: /conf/zone-query/subset Abstract test A.19: /conf/zone-query/subset-crs Abstract test A.20: /conf/zone-query/datetime |
A.6.1. Abstract Test for Requirement Listing zones
| Identifier | /conf/zone-query/zones-list |
|---|---|
| Requirement | Requirement 11: /req/zone-query/zones-list |
| Test purpose | Verify that the Implementation supports querying DGGRS zones |
| Test method | Given: a DGGRS zones query resource identified from a [ogc-rel:dggrs-zone-query] link |
A.6.2. Abstract Test for Requirement JSON zone list encoding
| Identifier | /conf/zone-query/json-response |
|---|---|
| Requirement | Requirement 12: /req/zone-query/json-response |
| Test purpose | Verify that the Implementation supports returning a list of DGGS zones encoded as JSON |
| Test method | Given: a DGGRS zones query resource identified from a [ogc-rel:dggrs-zone-query] link |
A.6.3. Abstract Test for Requirement zone-level query parameter
| Identifier | /conf/zone-query/zone-level |
|---|---|
| Requirement | Requirement 13: /req/zone-query/zone-level |
| Test purpose | Verify that the Implementation supports specifying a level at which to return a list of DGGS zones using a zone-level query parameter |
| Test method | Given: a DGGRS zones query resource identified from a [ogc-rel:dggrs-zone-query] link which passed the /zone-query/zones-list abstract test |
A.6.4. Abstract Test for Requirement compact-zones query parameter
| Identifier | /conf/zone-query/compact-zones |
|---|---|
| Requirement | Requirement 14: /req/zone-query/compact-zones |
| Test purpose | Verify that the Implementation supports specifying whether to retrieve a list of DGGS zones using a compact-zones query parameter |
| Test method | Given: a DGGRS zones query resource identified from a [ogc-rel:dggrs-zone-query] link which passed the /zone-query/zones-list abstract test |
A.6.5. Abstract Test for Requirement parent-zone query parameter
| Identifier | /conf/zone-query/parent-zone |
|---|---|
| Requirement | Requirement 15: /req/zone-query/parent-zone |
| Test purpose | Verify that the Implementation supports specifying a parent zone within which to restrict zone listing using a parent-zone query parameter |
| Test method | Given: a DGGRS zones query resource identified from a [ogc-rel:dggrs-zone-query] link which passed the /zone-query/zones-list abstract test |
A.6.6. Abstract Test for Requirement bbox query parameter
| Identifier | /conf/zone-query/bbox |
|---|---|
| Requirement | Requirement 16: /req/zone-query/bbox |
| Test purpose | Verify that the Implementation supports specifying a spatial bounding box for which to return a list of DGGS zones |
| Test method | Given: a DGGRS zones query resource identified from a [ogc-rel:dggrs-zone-query] link which passed the /zone-query/zones-list abstract test |
A.6.7. Abstract Test for Requirement bbox-crs query parameter
| Identifier | /conf/zone-query/bbox-crs |
|---|---|
| Requirement | Requirement 17: /req/zone-query/bbox-crs |
| Test purpose | Verify that the Implementation supports specifying the CRS used for the bbox query parameter using the bbox-crs parameter |
| Test method | Given: a DGGRS zones query resource identified from a [ogc-rel:dggrs-zone-query] link which passed the /zone-query/zones-list abstract test and a collection |
A.6.8. Abstract Test for Requirement subset query parameter
| Identifier | /conf/zone-query/subset |
|---|---|
| Requirement | Requirement 18: /req/zone-query/subset |
| Test purpose | Verify that the Implementation supports specifying a spatial bounding box for which to return a list of DGGS zones |
| Test method | Given: a DGGRS zones query resource identified from a [ogc-rel:dggrs-zone-query] link which passed the /zone-query/zones-list abstract test |
A.6.9. Abstract Test for Requirement subset-crs query parameter
| Identifier | /conf/zone-query/subset-crs |
|---|---|
| Requirement | Requirement 19: /req/zone-query/subset-crs |
| Test purpose | Verify that the Implementation supports specifying the CRS used for the bbox query parameter using the bbox-crs query parameter |
| Test method | Given: a DGGRS zones query resource identified from a [ogc-rel:dggrs-zone-query] link which passed the /zone-query/zones-list abstract test and a collection |
A.6.10. Abstract Test for Requirement datetime query parameter
| Identifier | /conf/zone-query/datetime |
|---|---|
| Requirement | Requirement 20: /req/zone-query/datetime |
| Test purpose | Verify that the Implementation supports specifying a multi-dimensional subset for which to return a list of DGGS zones |
| Test method | Given: a DGGRS zones query resource identified from a [ogc-rel:dggrs-zone-query] link which passed the /zone-query/zones-list abstract test |
A.7. Conformance Class “Filtering Zone Queries with CQL2”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/zone-query-cql2-filter |
|---|---|
| Requirements class | Requirements class 7: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-query-cql2-filter |
| Target Type | Web API |
| Conformance test | Abstract test A.21: /conf/zone-query-cql2-filter/filter |
A.7.1. Abstract Test for Requirement filter query parameter (for zone queries)
| Identifier | /conf/zone-query-cql2-filter/filter |
|---|---|
| Requirement | Requirement 21: /req/zone-query-cql2-filter/filter |
| Test purpose | Verify that the Implementation supports specifying a CQL2 expression filtering the zones returned from a zone query |
| Test method | Given: a DGGRS zones query resource identified from a [ogc-rel:dggrs-zone-query] link which passed the /zone-query/zones-list abstract test |
A.8. Conformance Class “Root DGGS”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/root-dggs |
|---|---|
| Requirements class | Requirements class 8: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/root-dggs |
| Target Type | Web API |
| Conformance test | Abstract test A.22: /conf/root-dggs/dggs |
A.8.1. Abstract Test for Requirement Root DGGS
| Identifier | /conf/root-dggs/dggs |
|---|---|
| Requirement | Requirement 22: /req/root-dggs/dggs |
| Test purpose | Verify that the Implementation supports API/dataset-wide DGGS resources |
| Test method | Given: an implementation declaring conformance to Root DGGS |
A.9. Conformance Class “Collection DGGS”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/collection-dggs |
|---|---|
| Requirements class | Requirements class 9: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/collection-dggs |
| Target Type | Web API |
| Conformance test | Abstract test A.23: /conf/collection-dggs/dggs |
A.9.1. Abstract Test for Requirement Collection DGGS
| Identifier | /conf/collection-dggs/dggs |
|---|---|
| Requirement | Requirement 23: /req/collection-dggs/dggs |
| Test purpose | Verify that the Implementation supports collection DGGS resources |
| Test method | Given: an implementation declaring conformance to Collection DGGS |
A.10. Conformance Class “DGGS-JSON zone data encoding”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-json |
|---|---|
| Requirements class | Requirements class 10: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-json |
| Target Type | Web API |
| Conformance test | Abstract test A.24: /conf/data-json/content |
A.10.1. Abstract Test for Requirement DGGS-JSON Zone data encoding
| Identifier | /conf/data-json/content |
|---|---|
| Requirement | Requirement 24: /req/data-json/content |
| Test purpose | Verify that the Implementation supports encoding zone data as DGGS-JSON |
| Test method | Given: a DGGRS zone data resource identified from a [ogc-rel:dggrs-zone-data] link template within a DGGRS description resource, replacing the {zoneId} variable with a known valid identifier for the DGGRS, not beyond the maxRefinementLevel if one is specified |
A.11. Conformance Class “DGGS-UBJSON zone data encoding”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-ubjson |
|---|---|
| Requirements class | Requirements class 11: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-ubjson |
| Target Type | Web API |
| Conformance test | Abstract test A.25: /conf/data-ubjson/content |
A.11.1. Abstract Test for Requirement DGGS-UBJSON Zone data encoding
| Identifier | /conf/data-ubjson/content |
|---|---|
| Requirement | Requirement 25: /req/data-ubjson/content |
| Test purpose | Verify that the Implementation supports encoding zone data as DGGS-UBJSON |
| Test method | Given: a DGGRS zone data resource identified from a [ogc-rel:dggrs-zone-data] link template within a DGGRS description resource, replacing the {zoneId} variable with a known valid identifier for the DGGRS, not beyond the maxRefinementLevel if one is specified |
A.12. Conformance Class “DGGS-JSON-FG zone data encoding”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-dggs-jsonfg |
|---|---|
| Requirements class | Requirements class 12: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-dggs-jsonfg |
| Target Type | Web API |
| Conformance test | Abstract test A.26: /conf/data-dggs-jsonfg/content |
A.12.1. Abstract Test for Requirement DGGS-JSON-FG Zone data encoding
| Identifier | /conf/data-dggs-jsonfg/content |
|---|---|
| Requirement | Requirement 26: /req/data-dggs-jsonfg/content |
| Test purpose | Verify that the Implementation supports encoding zone data as DGGS-JSON-FG |
| Test method | Given: a DGGRS zone data resource identified from a [ogc-rel:dggrs-zone-data] link template within a DGGRS description resource, replacing the {zoneId} variable with a known valid identifier for the DGGRS, not beyond the maxRefinementLevel if one is specified |
A.13. Conformance Class “DGGS-UBJSON-FG zone data encoding”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-dggs-ubjsonfg |
|---|---|
| Requirements class | Requirements class 13: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-dggs-ubjsonfg |
| Target Type | Web API |
| Conformance test | Abstract test A.27: /conf/data-dggs-ubjsonfg/content |
A.13.1. Abstract Test for Requirement DGGS-UBJSON-FG Zone data encoding
| Identifier | /conf/data-dggs-ubjsonfg/content |
|---|---|
| Requirement | Requirement 27: /req/data-dggs-ubjsonfg/content |
| Test purpose | Verify that the Implementation supports encoding zone data as DGGS-UBJSON-FG |
| Test method | Given: a DGGRS zone data resource identified from a [ogc-rel:dggrs-zone-data] link template within a DGGRS description resource, replacing the {zoneId} variable with a known valid identifier for the DGGRS, not beyond the maxRefinementLevel if one is specified |
A.14. Conformance Class “GeoTIFF zone data encoding”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-geotiff |
|---|---|
| Requirements class | Requirements class 14: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-geotiff |
| Target Type | Web API |
| Conformance test | Abstract test A.28: /conf/data-geotiff/content |
A.14.1. Abstract Test for Requirement GeoTIFF Zone data encoding
| Identifier | /conf/data-geotiff/content |
|---|---|
| Requirement | Requirement 28: /req/data-geotiff/content |
| Test purpose | Verify that the Implementation supports encoding zone data as GeoTIFF |
| Test method | Given: a DGGRS zone data resource identified from a [ogc-rel:dggrs-zone-data] link template within a DGGRS description resource, replacing the {zoneId} variable with a known valid identifier for the DGGRS, not beyond the maxRefinementLevel if one is specified |
A.15. Conformance Class “GeoJSON zone data encoding”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-geojson |
|---|---|
| Requirements class | Requirements class 15: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-geojson |
| Target Type | Web API |
| Conformance test | Abstract test A.29: /conf/data-geojson/content |
A.15.1. Abstract Test for Requirement GeoJSON Zone data encoding
| Identifier | /conf/data-geojson/content |
|---|---|
| Requirement | Requirement 29: /req/data-geojson/content |
| Test purpose | Verify that the Implementation supports encoding zone data as GeoJSON |
| Test method | Given: a DGGRS zone data resource identified from a [ogc-rel:dggrs-zone-data] link template within a DGGRS description resource, replacing the {zoneId} variable with a known valid identifier for the DGGRS, not beyond the maxRefinementLevel if one is specified |
A.16. Conformance Class “netCDF zone data encoding”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-netcdf |
|---|---|
| Requirements class | Requirements class 16: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-netcdf |
| Target Type | Web API |
| Conformance test | Abstract test A.30: /conf/data-netcdf/content |
A.16.1. Abstract Test for Requirement netCDF Zone data encoding
| Identifier | /conf/data-netcdf/content |
|---|---|
| Requirement | Requirement 30: /req/data-netcdf/content |
| Test purpose | Verify that the Implementation supports encoding zone data as netCDF |
| Test method | Given: a DGGRS zone data resource identified from a [ogc-rel:dggrs-zone-data] link template within a DGGRS description resource, replacing the {zoneId} variable with a known valid identifier for the DGGRS, not beyond the maxRefinementLevel if one is specified |
A.17. Conformance Class “Zarr zone data encoding”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-zarr |
|---|---|
| Requirements class | Requirements class 17: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-zarr |
| Target Type | Web API |
| Conformance test | Abstract test A.31: /conf/data-zarr/content |
A.17.1. Abstract Test for Requirement Zarr Zone data encoding
| Identifier | /conf/data-zarr/content |
|---|---|
| Requirement | Requirement 31: /req/data-zarr/content |
| Test purpose | Verify that the Implementation supports encoding zone data as zipped Zarr 2 |
| Test method | Given: a DGGRS zone data resource identified from a [ogc-rel:dggrs-zone-data] link template within a DGGRS description resource, replacing the {zoneId} variable with a known valid identifier for the DGGRS, not beyond the maxRefinementLevel if one is specified |
A.18. Conformance Class “CoverageJSON zone data encoding”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-coveragejson |
|---|---|
| Requirements class | Requirements class 18: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-coveragejson |
| Target Type | Web API |
| Conformance test | Abstract test A.32: /conf/data-coveragejson/content |
A.18.1. Abstract Test for Requirement CoverageJSON Zone data encoding
| Identifier | /conf/data-coveragejson/content |
|---|---|
| Requirement | Requirement 32: /req/data-coveragejson/content |
| Test purpose | Verify that the Implementation supports encoding zone data as CoverageJSON |
| Test method | Given: a DGGRS zone data resource identified from a [ogc-rel:dggrs-zone-data] link template within a DGGRS description resource, replacing the {zoneId} variable with a known valid identifier for the DGGRS, not beyond the maxRefinementLevel if one is specified |
A.19. Conformance Class “JPEG XL zone data encoding”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-jpegxl |
|---|---|
| Requirements class | Requirements class 19: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-jpegxl |
| Target Type | Web API |
| Conformance test | Abstract test A.33: /conf/data-jpegxl/content |
A.19.1. Abstract Test for Requirement JPEG XL Zone data encoding
| Identifier | /conf/data-jpegxl/content |
|---|---|
| Requirement | Requirement 33: /req/data-jpegxl/content |
| Test purpose | Verify that the Implementation supports encoding zone data as JPEG XL |
| Test method | Given: a DGGRS zone data resource identified from a [ogc-rel:dggrs-zone-data] link template within a DGGRS description resource, replacing the {zoneId} variable with a known valid identifier for the DGGRS, not beyond the maxRefinementLevel if one is specified |
A.20. Conformance Class “PNG zone data encoding “
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-png |
|---|---|
| Requirements class | Requirements class 20: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-png |
| Target Type | Web API |
| Conformance test | Abstract test A.34: /conf/data-png/content |
A.20.1. Abstract Test for Requirement PNG Zone data encoding
| Identifier | /conf/data-png/content |
|---|---|
| Requirement | Requirement 34: /req/data-png/content |
| Test purpose | Verify that the Implementation supports encoding zone data as PNG |
| Test method | Given: a DGGRS zone data resource identified from a [ogc-rel:dggrs-zone-data] link template within a DGGRS description resource, replacing the {zoneId} variable with a known valid identifier for the DGGRS, not beyond the maxRefinementLevel if one is specified |
A.21. Conformance Class “HTML zone list encoding”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/zone-html |
|---|---|
| Requirements class | Requirements class 21: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-html |
| Target Type | Web API |
| Conformance test | Abstract test A.35: /conf/zone-html/content |
A.21.1. Abstract Test for Requirement HTML zone list encoding
| Identifier | /conf/zone-html/content |
|---|---|
| Requirement | Requirement 35: /req/zone-html/content |
| Test purpose | Verify that the Implementation supports encoding zone lists as HTML |
| Test method | Given: a DGGRS zones query resource identified from a [ogc-rel:dggrs-zone-query] link |
A.22. Conformance Class “Binary 64-bit integer zone list encoding”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/zone-uint64 |
|---|---|
| Requirements class | Requirements class 22: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-uint64 |
| Target Type | Web API |
| Conformance test | Abstract test A.36: /conf/zone-uint64/content |
A.22.1. Abstract Test for Requirement Binary 64-bit integer zone list encoding
| Identifier | /conf/zone-uint64/content |
|---|---|
| Requirement | Requirement 36: /req/zone-uint64/content |
| Test purpose | Verify that the Implementation supports encoding zone lists as 64-bit unsigned integer |
| Test method | Given: a DGGRS zones query resource identified from a [ogc-rel:dggrs-zone-query] link |
A.23. Conformance Class “GeoJSON zone list encoding “
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/zone-geojson |
|---|---|
| Requirements class | Requirements class 23: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-geojson |
| Target Type | Web API |
| Conformance test | Abstract test A.37: /conf/zone-geojson/content |
A.23.1. Abstract Test for Requirement GeoJSON zone list encoding
| Identifier | /conf/zone-geojson/content |
|---|---|
| Requirement | Requirement 37: /req/zone-geojson/content |
| Test purpose | Verify that the Implementation supports encoding zone lists as GeoJSON |
| Test method | Given: a DGGRS zones query resource identified from a [ogc-rel:dggrs-zone-query] link |
A.24. Conformance Class “GeoTIFF zone list encoding”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/zone-geotiff |
|---|---|
| Requirements class | Requirements class 24: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/zone-geotiff |
| Target Type | Web API |
| Conformance test | Abstract test A.38: /conf/zone-geotiff/content |
A.24.1. Abstract Test for Requirement GeoTIFF zone list encoding
| Identifier | /conf/zone-geotiff/content |
|---|---|
| Requirement | Requirement 38: /req/zone-geotiff/content |
| Test purpose | Verify that the Implementation supports encoding zone lists as GeoTIFF |
| Test method | Given: a DGGRS zones query resource identified from a [ogc-rel:dggrs-zone-query] link |
A.25. Conformance Class “Operation IDs”
| Identifier | https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/operation-ids |
|---|---|
| Requirements class | Requirements class 25: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/operation-ids |
| Target Type | Web API |
| Conformance test | Abstract test A.39: /conf/operation-ids/operation-ids |
A.25.1. Abstract Test for Operation IDs
| Identifier | /conf/operation-ids/operation-ids |
|---|---|
| Requirement | Requirement 39: /req/operation-ids/operation-ids |
| Test purpose | Verify that the correct operation IDs suffixed are used in the API definition to identify DGGS resources |
| Test method | Given: a DGGS API implementation providing an API definition with a concept of operation IDs (such as OpenAPI 3.0) |
Annex B
(informative)
Discrete Global Grid Reference System Definitions
The following informative schema describes the expected response of the resource linked to by using the [ogc-rel:dggrs-definition] link relation from the DGGRS description. This behavior is specified by the Core requirements class. An important objective for this schema is to support establishing authoritative registries of DGGRSs providing a URI for a DGGRS corresponding to a specific definition.
Note that this schema is preliminary, and a normative version may be defined in a later version of the OGC API — DGGS Standard or by a future part of OGC Abstract Specification Topic 21. The schema may change to support a better description of existing and new classes of DGGH.
The DGGRS definition consists of three main components:
The definition of the hierarchy of discrete global grids (dggh), including any parameterization such as the spheroid or orientation, establishing both the topology as well as the geometry of every zone,
The Zonal Identifier Reference System (zirs), with textual identifiers being mandatory while 64-bit integer identifiers (which support the 64-bit integer zone list encoding requirements class) are optional,
The sub-zone ordering (subZoneOrder), which allows for retrieving zone data using e.g., DGGS-JSON at a zone-depth other than 0 (the values of sub-zones can be provided as a 1D array of values with a pre-established association to sub-zones).
Whereas the ZIRS provides a mechanism to globally identify a single zone using a textual identifier (and alternatively using a 64-bit integer), the deterministic sub-zone order provides a local indexing mechanism to address smaller regions within a particular zone. This local indexing mechanism enables the DGGS-optimized data encodings defined by the DGGS-JSON and DGGS-JSON-FG requirements classes. The two mechanisms may potentially be related to each other, for example using the same space filling curve such as a Morton code (Z-order curve), but do not need to be. If defining a more optimal sub-zone order for a particular DGGRS is not practical, the ascending sort order of the sub-zone identifiers can be specified as a fallback, based on either the ASCII character strings of the textual identifiers, or the 64-bit integer identifiers.
IMPORTANT
When defining sub-zone order based on a space-filling curve, the curve must go through every sub-zone of the parent zone (all zones at least partially within the parent zone), and if the curve goes through zones fully outside of the parent zone, those outside zones must be excluded from this local indexing order, as they are not considered sub-zones.
NOTE: Some of the DGGRS definitions in this annex include a projString property which is not part of the DGGRS definition. This is provided in the hope of improving the understanding of the specific coordinate reference system used, as an alternative to a registered URI or a more verbose CRS definition in an encoding such as CRS JSON or PROJJSON (whose potential harmonization are still a subject of discussion). The inclusion of this projString is not to be understood as an endorsement of any particular software library, and is not expected to be present in an eventual authoritative DGGRS register after the corresponding CRS has been registered and is referenceable by URI and/or the CRS JSON schema is finalized.
B.1. JSON Schema for defining a DGGRS
{
"$schema": "https://json-schema.org/draft/2019-09/schema",
"description": "Discrete Global Grid System Reference System (DGGRS) Definition. This provisional schema is provided as informative guidance until a normative OGC Topic 21 - Part 5: DGGRS Definition Schema is finalized. DGGRS descriptions for OGC API - DGGS must link to such a definition using the link relation type http://www.opengis.net/def/rel/ogc/1.0/dggrs-definition. A JSON DGGRS definition is intended to provide a complete and unambiguous definition of a DGGRS, including the topology of the grids hierarchy, the mapping to a particular underlying Earth model, the zone identifier reference system and the deterministic sub-zone order, allowing to implement the OGC API - DGGS functionality for that DGGRS in interoperable clients and servers. At least until a normative schema is published as a Topic 21 part, clients should rely on matching URIs associated with specific DGGRS definitions they recognize rather than attempt to parse the definition's content. This is intentionally included in the OGC API - DGGS example OpenAPI definition for reference, but unused in resource paths, since the API is only required to provide a link, but not necessarily host the definition itself at any partiular resource path.",
"type": "object",
"required": [
"dggh",
"zirs",
"subZoneOrder"
],
"properties": {
"title": {
"type": "string",
"description": "A short human readable title or name for this DGGRS"
},
"description": {
"type": "string",
"description": "A summary textual description of this DGGRS"
},
"uri": {
"type": "string",
"format": "uri",
"description": "The authoritative URI associated with this DGGRS definition"
},
"dggh": {
"type": "object",
"description": "The hierarchical series of Discrete Global Grid upon which this DGGRS is based, including any parameters.",
"properties": {
"definition": {
"description": "The base definition of the hierarchical series of Discrete Global Grid, which may be parameterized.",
"type": "object",
"required": [
"spatialDimensions",
"temporalDimensions"
],
"properties": {
"crs": {
"allOf": [
{
"description": "The native Coordinate Reference System (CRS) in which the geometry of the zones for this DGG hierarchy is defined."
},
{
"anyOf": [
{
"type": "string",
"format": "uri",
"example": "EPSG:7789"
},
{
"type": "object"
}
]
}
]
},
"basePolyhedron": {
"type": "string",
"description": "The Type/Class of Polyhedron used to construct the Discrete Global Grid System - if it is constructued using a Base Polyhedron.",
"example": "icosahedron"
},
"refinementRatio": {
"description": "The ratio of the area of zones between two consecutive hierarchy level (the ratio of child zones to parent zones, also called the aperture).",
"example": 9,
"type": "integer"
},
"constraints": {
"type": "object",
"properties": {
"cellAxisAligned": {
"description": "Set to true if all edges of the geometry of all zones are aligned with one of the axis of the `crs`.",
"type": "boolean",
"default": false
},
"cellConformal": {
"type": "boolean",
"default": false
},
"cellEquiAngular": {
"type": "boolean",
"default": false
},
"cellEquiDistant": {
"type": "boolean",
"default": false
},
"cellEqualSized": {
"description": "Set to true if the area of all zones is the same for a particular zone geometry type of any specifc discrete global grid of the DGG hierarchy.",
"type": "boolean",
"default": false
}
}
},
"spatialDimensions": {
"description": "Number of Spatial Dimensions defined by the Discrete Global Grid System.",
"example": 2,
"type": "integer"
},
"temporalDimensions": {
"description": "Number of Temporal Dimensions defined by the Discrete Global Grid System.",
"example": 0,
"type": "integer"
},
"zoneTypes": {
"type": "array",
"items": {
"anyOf": [
{ "type": "string" },
{
"type": "string",
"enum": [
"triangle",
"square",
"hexagon",
"pentagon",
"rhombus"
]
}
]
},
"example": [
"hexagon",
"pentagon"
]
},
"refinementStrategy": {
"description": "The refinement strategy used by the Discrete Global Grid System",
"type": "array",
"items": {
"type": "string",
"enum": [
"centredChildCell",
"nestedChildCell",
"nodeCentredChildCell",
"nodeSharingChildCell",
"edgeCentredChildCell",
"faceCentredChildCell",
"solidCentredChildCell"
]
},
"example": [ "nestedChildCell" ]
}
}
},
"parameters": {
"description": "The optional parameters establishing a very specific Discrete Global Grid System, where each zone has a well-defined geometry.",
"type": "object",
"properties": {
"ellipsoid": {
"type": "string",
"format": "uri",
"description": "Globe Reference System Identifier/Specification",
"example": [
"EPGS:7019"
]
},
"orientation": {
"type": "object",
"properties": {
"latitude": {
"description": "Reference geodetic Latitude in decimal degrees to fix the orientation of the polyhedron.",
"example": 58.397145907431,
"type": "number"
},
"longitude": {
"description": "Reference Longitude in decimal degrees to fix the orientation of the polyhedron.",
"example": 11.20,
"type": "number"
},
"azimuth": {
"description": "Azimuth in decimal degrees of second vertex relative to the first vertex.",
"example": 0.0,
"type": "number",
"default": 0.0
},
"description": {
"type": "string"
}
},
"required": [
"longitude",
"latitude"
]
}
}
}
}
},
"zirs": {
"description": "The Zone Identifier Reference System used for this Discrete Global Grid System Reference System.",
"type": "object",
"required": [
"textZIRS"
],
"properties": {
"textZIRS": {
"description": "textual zone identifier indexing scheme",
"type": "object",
"required": [
"description"
],
"properties": {
"description": {
"type": "string",
"examples": [
"Topological Morton Code (Space Filling Curve) Identifier. With a Level 0 alphabetical identifier from 'A' to 'S' followed by a numeric reference from 1 to 9 for all subsequent levels representing the arrangement of child zones following a Morton (Z-code) subdivision of the parent zone. The length of the identifier represents the level of refinement.",
"Universal Morton Code (Space Filling Curve) Identifier. An ellipsoidal bitwise concatenation of longitude and latitude direct position to form a direct Morton code. This can be used across multiple DGGS infrastructures to provide a common index structure that is fixed in nature regardless of the topological zone index used by each DGGS.",
"An identifier comprised of three separate level, row and column components corresponding to an OGC 2D Tile Matrix Set tile identifier, where the individual component are represented by uppercase hexadecimal numbers separated by a hyphen.",
"An identifier comprised of an uppercase letter representing a level (A for level 0, B for level 1...), followed by a number from 0 to 9 representing the root rhombus corresponding to the faces of an icosahedron, in a staircase order from the top-left to the bottom right of an ISEA planar projection after a 60 degrees clockwise rotation, followed by a hyphen, then by an uppercase hexadecimal number identifying a sub-zone starting to count from 0 in row-major order.",
"An identifier comprised of an uppercase letter representing the ISEA9R level corresponding to the current even or immediate lower odd ISEA3H level (A for level 0, B for level 1...), followed by a number from 0 to 9 representing the root rhombus corresponding to the faces of an icosahedron, in a staircase order from the top-left to the bottom right of an ISEA planar projection after a 60 degrees clockwise rotation, followed by a hyphen, then by an uppercase hexadecimal number identifying a sub-zone starting to count from 0 in row-major order, followed by a second hyphen, then by a letter identifying a hexagonal or pentagonal zone intersecting the sub-rhombus: A: even level regular zone B: even level North pole zone C: even level South pole zone D: odd level zone centered on rhombus vertex E: odd level zone top-right of rhombus vertex F: odd level zone bottom-right of rhombus vertex G: odd level North pole zone H: odd level South pole zone\n"
]
},
"type": {
"anyOf": [
{
"type": "string"
},
{
"type": "string",
"enum": [
"hierarchicalConcatenation",
"ogc2DTMSHexLevelRowCol",
"levelRootFaceHexRowMajorSubZone"
]
}
]
}
}
},
"uint64ZIRS": {
"description": "64-bit unsigned integer zone indexing scheme",
"type": "object",
"required": [
"description"
],
"properties": {
"description": {
"type": "string",
"examples": [
"A 64-bit integer with the 30 least significant bits corresponds to a column, the next 29 bits corresponding to a row, and the 5 most significant bits correspond to a level of an OGC 2D Tile Matrix Set identifier, with individual components using little endian.",
"A 64-bit integer with the 3 least significant bits corresponding to a hexagonal or pentagonal zone intersecting a sub-rhombus: 0: even level regular zone 1: even level North pole zone 2: even level South pole zone 3: odd level zone centered on rhombus vertex 4: odd level zone top-right of rhombus vertex 5: odd level zone bottom-right of rhombus vertex 6: odd level North pole zone 7: odd level South pole zone, the next 51 bits corresponding to a sub-rhombus index, the next 4 bits corresponding to a root rhombus, the next 5 bits corresponding to an associated ISEA9R level, and the last most significant bit always 0 for a valid zone identifier.\n"
]
},
"type": {
"anyOf": [
{
"type": "string"
},
{
"type": "string",
"enum": [
"ogc2DTMSHexLevelRowCol"
]
}
]
}
}
}
}
},
"subZoneOrder": {
"description": "The ordering used for this Discrete Global Grid System Reference System when encoding the values associated with sub-zones at any given depth relative to a parent zone.",
"type": "object",
"required": [
"description"
],
"properties": {
"description": {
"type": "string",
"examples": [
"The zones are ordered in tightly packed scanlines. For an odd relative depth, scanlines start along a hexagon edge, whereas for even relative depths, scanlines start on a hexagon vertex. Scanlines run in a clockwise direction. For sub-zones at an even refinement level, zones are ordered left to right along a scanline and scanlines are ordered from top to bottom (considering the ISEA planar projection). For sub-zones at an odd refinement level, zones are ordered top to bottom along a scanline and scanlines are ordered from left to right. Sub-zones are at an even refinement level when the parity (even/odd) of the parent zone level corresponds to the parity of the relative depth, and at an odd refinement level when the parity of the parent zone level and relative depth do not match. For polar pentagons, the orientation of the scanlines varies in the ISEA planar projection but is always clockwise, the vertex/edge of the first sub-zone is on the left side of the planar ISEA projection for the north pole (in root rhombus 0), and on the right side for the south pole (in root rhombus 9)."
]
},
"type": {
"anyOf": [
{
"type": "string"
},
{
"type": "string",
"enum": [
"scanline",
"spiralFromCenter",
"mortonCurve",
"hilbertCurve"
]
}
]
}
}
}
}
}
Listing B.1 — JSON Schema for the DGGRS Definition
The following example JSON DGGRS definitions conform to this schema.
B.2. ISEA9R DGGRS definition
The following DGGRS is for an axis-aligned and equal-area DGGH based on the Icosahedral Snyder Equal-Area (ISEA) planar projection (see PROJ and geogrid for open-source implementations) using rhombuses with a refinement ratio of 9. When the ISEA projection is rotated clockwise 60 degrees, sheared horizontally by a -60 degrees angle, and units are mapped to a 5×6 space, the zones become square and their edges are aligned with the CRS axes, while remaining equal area. A 2D Tile Matrix Set can also be defined in this transformed CRS, allowing for compatibility with OGC API — Tiles, WMTS and traditional client and visualization software with no built-in DGGS functionality. This transformed CRS distorts angles and distances more than the planar ISEA projection, but the topology, indexing, and surface geometry on the Earth model remains the same as in that planar ISEA projection.
While the ISEA projection is defined for an authalic sphere, this DGGRS assumes that when importing or exporting data referenced to the WGS84 ellipsoid a conversion between geodetic and authalic latitude is performed. This guarantees that all zones are exactly the same area on the surface of the ellipsoid.
NOTE: The authalic (meaning “area preserving”) sphere is a sphere that has the same surface area as the oblate ellipsoid being used.
{
"title": "ISEA9R",
"description": "An ISEA9R Discrete Global Grid Reference System using an ISEA orientation symmetric about the equator with a single vertex on land, and WGS84 authalic sphere (a WGS84 geodetic latitude is mapped to the sphere by converting it to an authalic latitude), a {level}{rootRhombus}-{hexSubZone} indexing system, and scanline-based sub-zone ordering. The ten root rhombuses are formed by combining two icosahedron triangles at their base. Depending on whether the ISEA planar CRS is rotated, sheared and scaled or not, the geometries of the zones are either squares or rhombuses, and the zone edges are either axis-aligned, or the angles and distances are preserved. In either case, the topology, indexing and surface geometry on the Earth model remains the same. The ISEA9R DGGH is a dual of the ISEA3H DGGH even levels (a vertex/node in ISEA9R is the centroid of an ISEA3H zone).",
"uri": "https://www.opengis.net/def/dggrs/OGC/1.0/ISEA9R",
"links": [ { "rel": "describedby", "href": "https://www.opengis.net/doc/is/ogcapi-dggs/1.0" } ],
"dggh": {
"definition": {
"spatialDimensions": 2,
"temporalDimensions": 0,
"crs": "https://www.opengis.net/def/crs/OGC/0/153456",
"projString": "+proj=pipeline +step +proj=isea +R=6371007.18091847 +x_0=19186144.8709340879 +y_0=-3323137.7717834860 +step +proj=affine +inv +s11=3837228.974186818 +s12=3837228.974186818 +s21=6646275.543566972 +s22=-6646275.543566972",
"links": [
{ "rel": "related", "href": "https://doi.org/10.3138/27H7-8K88-4882-1752" },
{ "rel": "related", "href": "https://proj.org/en/9.3/operations/projections/isea.html" }
],
"basePolyhedron": "icosahedron",
"refinementRatio": 9,
"refinementStrategy": [ "nestedChildCell", "nodeCentredChildCell" ],
"constraints": {
"cellAxisAligned": true,
"cellEqualSized": true
},
"zoneTypes": [ "square" ]
},
"parameters": {
"ellipsoid": "[EPSG:7030]",
"orientation":
{
"description": "ISEA orientation symmetric about the equator with a single icosahedron vertex falling on land, with first icosahedron vertex at authalic latitude equal to the arctangent of the golden ratio (~58.397145907431° N geodetic latitude), 11.20°E longitude, and second vertex due North from that first vertex.",
"latitude": 58.397145907431,
"longitude": 11.20,
"azimuth": 0
}
}
},
"zirs": {
"textZIRS": {
"description": "An identifier comprised of an uppercase letter representing a level (A for level 0, B for level 1...), followed by a number from 0 to 9 representing the root rhombus corresponding to the faces of an icosahedron, in a staircase order from the top-left to the bottom right of an ISEA planar projection after a 60 degrees clockwise rotation, followed by a hyphen, then by an uppercase hexadecimal number identifying a sub-zone starting to count from 0 in row-major order.",
"type": "levelRootFaceHexRowMajorSubZone"
},
"uint64ZIRS": {
"description": "A 64-bit integer with the 30 least significant bits corresponds to a column, the next 29 bits corresponding to a row, and the 5 most significant bits correspond to a level of an OGC 2D Tile Matrix Set identifier, with individual components using little endian.",
"type": "ogc2DTMSHexLevelRowCol"
}
},
"subZoneOrder": {
"description": "The zones are ordered as scanlines in row-major order, left to right, then top to bottom, based on a CRS derived from the planar ISEA projection after rotating it 60° clockwise (-60° rotation) and applying a -60° degrees horizontal shear.",
"type": "scanline"
}
}
Listing B.2 — DGGRS Definition for ISEA9R
Figure B.1 — The ISEA9R squared root rhombuses (level 0) in the rotated and sheared ISEA planar CRS mapped to a 5x6 space whose axes are aligned with the zone edges, compatible with a 2DTMS definition (imagery from NASA Earth Observatory’s Blue Marble: Next Generation)
Figure B.2 — The ISEA9R level 0 zone identifiers, shown in the original ISEA planar CRS (GEBCO 2014 bathymetry)
Figure B.3 — The ISEA9R level 1 zone identifiers, shown in the original ISEA planar CRS (GEBCO 2014 bathymetry)
B.3. IVEA9R DGGRS definition
The IVEA9R DGGRS is very similar to the ISEA9R DGGRS described above, but using the Icosahedral Vertex-oriented Equal-Area (IVEA) projection (vanLeuuwen2006) instead of ISEA. Rather than mapping to straight lines great circles originating from the center of the icosahedron vertices, IVEA uses great circles originating from the icosahedron vertices. In terms of how each of the 120 spherical triangles of the disdyakis triacontahedron, which constitute the full spherical icosahedral symmetry, are mapped to flat triangles, this is actually equivalent to applying Snyder’s projection to the dodecahedron as illustrated in Figure 11 of Snyder’s 1992 paper Snyder1992 (which could be called “DSEA”), when considering the barycentric coordinates within the corresponding 120 projected triangles, but re-mapping them through an affine transformation to the net of the icosahedron. The IVEA projection avoids the perceptible cusps, or sharp changes in direction, of ISEA and therefore yields more regular shapes for zones which in turn should result in generally improved measures of the Goodchild criteria.
{
"title": "IVEA9R",
"description": "An IVEA9R Discrete Global Grid Reference System using the Icosahedral Vertex-oriented Equal-Area (IVEA) projection as described in the 2006 'Slice & Dice' publication (equivalent to applying the 1992 Snyder polyhedral projection to the dodecahedron when considering the barycentric coordinates within the projection of the spherical disdyakis triacontahedron triangles constituting full spherical icosahedral symmetry), an orientation symmetric about the equator with a single vertex on land, and WGS84 authalic sphere (a WGS84 geodetic latitude is mapped to the sphere by converting it to an authalic latitude), a {level}{rootRhombus}-{hexSubZone} indexing system, and scanline-based sub-zone ordering. The ten root rhombuses are formed by combining two icosahedron triangles at their base. Depending on whether the IVEA planar CRS is rotated, sheared and scaled or not, the geometries of the zones are either squares or rhombuses, and the zone edges are either axis-aligned, or the angles and distances are preserved. In either case, the topology, indexing and surface geometry on the Earth model remains the same. The IVEA9R DGGH is a dual of the IVEA3H DGGH even levels (a vertex/node in IVEA9R is the centroid of an IVEA3H zone).",
"uri": "https://www.opengis.net/def/dggrs/OGC/1.0/IVEA9R",
"links": [ { "rel": "describedby", "href": "https://www.opengis.net/doc/is/ogcapi-dggs/1.0" } ],
"dggh": {
"definition": {
"spatialDimensions": 2,
"temporalDimensions": 0,
"links": [
{ "rel": "related", "href": "https://doi.org/10.1559/152304006779500687" },
{ "rel": "related", "href": "https://doi.org/10.3138/27H7-8K88-4882-1752" }
],
"basePolyhedron": "icosahedron",
"refinementRatio": 9,
"refinementStrategy": [ "nestedChildCell", "nodeCentredChildCell" ],
"constraints": {
"cellAxisAligned": true,
"cellEqualSized": true
},
"zoneTypes": [ "square" ]
},
"parameters": {
"ellipsoid": "[EPSG:7030]",
"orientation":
{
"description": "IVEA orientation symmetric about the equator with a single icosahedron vertex falling on land, with first icosahedron vertex at authalic latitude equal to the arctangent of the golden ratio (~58.397145907431° N geodetic latitude), 11.20°E longitude, and second vertex due North from that first vertex.",
"latitude": 58.397145907431,
"longitude": 11.20,
"azimuth": 0
}
}
},
"zirs": {
"textZIRS": {
"description": "An identifier comprised of an uppercase letter representing a level (A for level 0, B for level 1...), followed by a number from 0 to 9 representing the root rhombus corresponding to the faces of an icosahedron, in a staircase order from the top-left to the bottom right of an IVEA planar projection after a 60 degrees clockwise rotation, followed by a hyphen, then by an uppercase hexadecimal number identifying a sub-zone starting to count from 0 in row-major order.",
"type": "levelRootFaceHexRowMajorSubZone"
},
"uint64ZIRS": {
"description": "A 64-bit integer with the 30 least significant bits corresponds to a column, the next 29 bits corresponding to a row, and the 5 most significant bits correspond to a level of an OGC 2D Tile Matrix Set identifier, with individual components using little endian.",
"type": "ogc2DTMSHexLevelRowCol"
}
},
"subZoneOrder": {
"description": "The zones are ordered as scanlines in row-major order, left to right, then top to bottom, based on a CRS derived from the planar IVEA projection after rotating it 60° clockwise (-60° rotation) and applying a -60° degrees horizontal shear.",
"type": "scanline"
}
}
Listing B.3 — DGGRS Definition for IVEA9R using same indexing and orientation as for ISEA9R
Figure B.4 — Comparison of ISEA9R (left) and IVEA9R (right) at refinement level 2
B.4. ISEA3H DGGRS definition
The following DGGRS is for an ISEA3H DGGH, also based on the ISEA planar projection, with hexagonal and pentagonal zones, and a refinement ratio of 3, using a zone reference system based in part on its dual relationship with the ISEA9R DGGH. The DGGH is considered equal area, although each of the 12 pentagonal zones at any level occupies 5/6th of the area of a hexagonal zone at the same level.
{
"title": "ISEA3H",
"description": "An ISEA3H Discrete Global Grid Reference System using an ISEA orientation symmetric about the equator with a single vertex on land, and WGS84 authalic sphere (a WGS84 geodetic latitude is mapped to the sphere by converting it to an authalic latitude), a zone indexing system based on an ISEA9R, and a scanline-based sub-zone ordering",
"uri": "https://www.opengis.net/def/dggrs/OGC/1.0/ISEA3H",
"links": [ { "rel": "describedby", "href": "https://www.opengis.net/doc/is/ogcapi-dggs/1.0" } ],
"dggh": {
"definition": {
"spatialDimensions": 2,
"temporalDimensions": 0,
"crs": "https://www.opengis.net/def/crs/OGC/0/1534",
"projString": "+proj=pipeline +step +proj=isea +R=6371007.18091847 +x_0=19186144.8709340879 +y_0=-3323137.7717834860",
"links": [
{ "rel": "related", "href": "https://doi.org/10.3138/27H7-8K88-4882-1752" },
{ "rel": "related", "href": "https://proj.org/en/9.3/operations/projections/isea.html" }
],
"basePolyhedron": "icosahedron",
"refinementRatio": 3,
"refinementStrategy": [ "centredChildCell", "nodeCentredChildCell" ],
"constraints": {
"cellEqualSized": true
},
"zoneTypes": [ "hexagon", "pentagon" ]
},
"parameters": {
"ellipsoid": "[EPSG:7030]",
"orientation":
{
"description": "ISEA orientation symmetric about the equator with a single icosahedron vertex falling on land, with first icosahedron vertex at authalic latitude equal to the arctangent of the golden ratio (~58.397145907431° N geodetic latitude), 11.20°E longitude, and second vertex due North from that first vertex.",
"latitude": 58.397145907431,
"longitude": 11.20,
"azimuth": 0
}
}
},
"zirs": {
"textZIRS": {
"description": "An identifier comprised of an uppercase letter representing the ISEA9R level corresponding to the current even or immediate lower odd ISEA3H level (A for level 0, B for level 1...), followed by a hexadecimal number from 0 to B, with 0 to 9 representing the root rhombus corresponding to the faces of an icosahedron, in a staircase order from the top-left to the bottom right of an ISEA planar projection after a 60 degrees clockwise rotation, A and B representing the special cases of the 'North' and 'South' poles respectively, followed by a hyphen, then by an uppercase hexadecimal number identifying a sub-rhombus starting to count from 0 in row-major order (except the special pole cases which are always 0), followed by a second hyphen, then by a letter identifying a hexagonal or pentagonal zone intersecting the sub-rhombus: A: even level, B: odd level zone centered on rhombus vertex, C: odd level zone top-right of rhombus vertex, D: odd level zone bottom-right of rhombus vertex\n",
"type": "levelRootFaceHexRowMajorSubZone"
},
"uint64ZIRS": {
"description": "A 64-bit integer with the 2 least significant bits corresponding to a hexagonal or pentagonal zone intersecting a sub-rhombus: 0: even level, 1: odd level zone centered on rhombus vertex, 2: odd level zone top-right of rhombus vertex, 3: odd level zone bottom-right of rhombus vertex, the next 51 bits corresponding to a sub-rhombus index (always 0 for polar zones), the next 4 bits corresponding to a root rhombus (with special values of 0xA and 0xB corresonding to North and South poles respectively), the next 5 bits corresponding to an associated ISEA9R level, and the remaining 2 most significant bits always 0 for a valid zone identifier."
}
},
"subZoneOrder": {
"description": "The zones are ordered in tightly packed scanlines. For an odd relative depth, scanlines start along a hexagon edge, whereas for even relative depths, scanlines start on a hexagon vertex. Scanlines run in a clockwise direction. For sub-zones at an even refinement level, zones are ordered left to right along a scanline and scanlines are ordered from top to bottom (considering the ISEA planar projection). For sub-zones at an odd refinement level, zones are ordered top to bottom along a scanline and scanlines are ordered from left to right. Sub-zones are at an even refinement level when the parity (even/odd) of the parent zone level corresponds to the parity of the relative depth, and at an odd refinement level when the parity of the parent zone level and relative depth do not match. For polar pentagons, the orientation of the scanlines varies in the ISEA planar projection but is always clockwise, the vertex/edge of the first sub-zone is on the left side of the planar ISEA projection for the north pole (in root rhombus 0), and on the right side for the south pole (in root rhombus 9).",
"type": "scanline"
}
}
Listing B.4 — DGGRS Definition for ISEA3H using indexing based on ISEA9R