Publication Date: 2021-01-13

Approval Date: 2020-12-14

Submission Date: 2020-11-19

Reference number of this document: OGC 20-039r2

Reference URL for this document: http://www.opengis.net/doc/PER/t16-D017

Category: OGC Public Engineering Report

Editor: Robert Gibb, Byron Cochrane, Matthew Purss

Title: OGC Testbed-16: DGGS and DGGS API Engineering Report


OGC Public Engineering Report

COPYRIGHT

Copyright © 2021 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/

WARNING

This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Public Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.

LICENSE AGREEMENT

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.

This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

Table of Contents

1. Subject

This OGC Testbed-16 Engineering Report (ER) documents the needs and key requirements for drafting an OGC Discrete Global Grid Systems (DGGS) Application Programming Interface (API) standard. The draft DGGS API is defined using the OpenAPI 3.0 specification. The work documented in this ER represents the beginning of a multi-initiative process to fully realize the benefits of standards compliant DGGS implementations and to help drive adoption of DGGS as a key element in advanced Spatial Data Architectures. The Testbed participants investigated a Client-Server DGGS architecture involving one (or more) DGGS Server implementations, DGGS-enabled Data Sources and a simple front-end DGGS Client. DGGS API functionality will be tested using one (or more) simple use case scenarios focusing on the two-way translation between geographic locations and DGGS Zonal Identifiers.

2. Executive Summary

2.1. Background and Expectations of the Testbed-16 DGGS thread

A Discrete Global Grid System (DGGS) represents a spherical partitioning of the Earth’s surface into a grid of cells (or zones) (Wikipedia). The OGC Members approved and maintain an Abstract Specification (AS) that captures the foundational concepts for DGGS (OGC 15-104r5). This Testbed task aims to begin the process to move towards an OGC Implementation Standard for DGGS through the creation of open-source DGGS reference implementations. Testbed-16 represents the initial effort of what is considered a multi-initiatives process.

DGGS offer a new way for geospatial information to be stored, visualized, and analyzed. Based on a partitioning of the Earth’s surface into a spherical grid, DGGS allows geospatial information to be represented in a way that more intuitively reflects relationships between data and the Earth’s surface. With DGGS, providers and consumers of geospatial information can eliminate many of the uncertainties and distortions inherently present with traditional coordinate systems. To fully realize the benefits of DGGS, standard-compliant implementations are required to allow zone-ID management across DGGS with varying structure and alignment.

DGGS presents an opportunity for the geospatial community to implement a representation of Earth that is vastly different from traditional coordinate system based approaches. DGGS has the potential to enable storage, analysis and visualization of geospatial information in a way that more accurately reflects the relationship between data and the Earth. While the OGC DGGS Abstract Specification captures fundamental DGGS concepts, the Testbed-16 DGGS thread initiated work to more concretely demonstrate DGGS in order to drive adoption. This includes advancement towards development of a DGGS reference implementation.

Key questions addressed by the work include:

  • What DGGS structure would be best for developing a reference implementation? For example, Uber’s Hexagonal Hierarchical Spatial Index or the Open Equal Area Global Grid (OpenEAGGR)

  • What is a simple application that could be used to demonstrate the value of the reference implementation?

  • What should be considered for future work oriented towards operational implementation of DGGS?

2.2. Summary of work undertaken

The participants in the Testbed-16 DGGS thread approached these questions by:

  1. Undertaking a review of what is needed from a DGGS library (DGGS and DGGS Reference System Selection) and introducing new terminology (Terms and definitions) to distinguish the different roles DGGS libraries can perform.

  2. Undertaking a review of existing open-source DGGS libraries against these roles and selecting two for use in the Testbed (DGGS and DGGS Reference System Selection).

    1. Uber’s H3 library

    2. Manaaki Whenua’s rHEALPix library

  3. Identifying candidate Use Cases, ideally that were both aligned with other Testbed-16 threads, and achievable with the current DGGS libraries and resources available to participants. (Use Cases)

  4. Identifying which OGC API would best demonstrate DGGS (DGGS API)

  5. Defining DGGS variants of OGC API - Features (OGC API - Features for DGGS description) and OGC API - Processes (OGC API - Processes for DGGS description).

  6. Developing server implementations and standing up server instances of each API:

    1. OGC API - Features (DGGS Enabled Data Services) as a native DGGS server,

    2. OGC API - Records (DGGS Enabled Data Services) as a discovery mechanism for the feature services, and

    3. OGC API - Processes (DGGS Server and API) on a native DGGS datastore wrapped by GeoServer.

  7. Populating each server with data covering the Australian Capital Territory (ACT) appropriate for the final Use Case.

    1. DGGS native data for Australian Statistical Area polygons and River Catchment polygons served through OGC API - Features (DGGS Enabled Data Services), and

    2. DGGS native Sentinel 2 data and processes to generate NDVI, NDBI & NDWI and band statistics served through OGC API - Processes (DGGS Server and API).

  8. Developing native DGGS desktop and Jupyter Notebook demonstration clients to interact with the two API (DGGS Demo Client).

  9. Exercising Jupyter Notebook client against the servers to show the Use Case in action.

  10. Mapping the Testbed-16 Data Access and Processing API (DAPA) onto the DGGS OGC API - Processes, to demonstrate a DGGS variant of the Testbed-16 DAPA (GeoServer DGGS based DAPA API).

  11. Reviewing participants experiences to assemble and prioritise recommendations for future work (Future Tasks).

2.3. Highlights from the Testbed-16 participants

Although DGGS implementations have been deployed in previous testbeds, this was the first time that a DGGS thread has appeared in an OGC Testbed. As a consequence, there were widely differing expectations both across the participants and between the participants and the sponsors. However, once all the participants had gained a common understanding of DGGS, progress was remarkably fast and a lot simpler than was anticipated.

Key highlights from this effort include:

  • Implementation of DGGS as a collection of virtual vector layers, allowing users to easily access various DGGS resolutions through formats best suited to their needs.

  • Demonstration of the ability of DGGS to incorporate widely used OGC standard services, allowing organizations to leverage past data and infrastructure investments in a new way.

  • Fast development of a robust Earth observation-oriented application, demonstrating the ability of DGGS to quickly and simply enable forms of analysis that are highly complex undertakings with traditional geospatial analysis techniques.

Both server implementations adopted a common strategy of wrapping the chosen DGGS libraries into their systems to present the DGGS Reference System (RS) as a collection of virtual vector layers. Each layer (or item in the collection) corresponds to a level of the DGGS RS grid hierarchy. In both API implementations this allowed the client to select whether it wanted a GeoJSON or a JSON payload. With the GeoJSON payload, the DGGS library created the necessary coordinates for each zone on-the-fly. With the JSON payload, a native DGGS geometry was supplied comprised only of DGGS zone-IDs (the unique identifier associated with each zone ).

For the GeoServer OGC API - Processes implementation this means that all the native GeoServer vector processing functionality, and all the existing GeoServer services - such as OGC WMS and OGC WFS - are exposed to traditional GeoServer clients to use DGGS data. A single GeoServer DGGS wrapper library was created to deliver both H3 and rHEALPix solutions. The no-SQL database ClickHouse was chosen as the GeoServer backend datastore for the DGGS data. This proved very fast for delivering Sentinel 2 data and generating both statistical summaries and index calculations (e.g. NDVI, NDBI & NDWI) on Sentinel 2 data. In the backend ClickHouse datastore, the DGGS zone ID was the primary index for the pixels of Sentinel 2 data.

In the OGC API - Features implementation, a linked data approach was taken using an Resource Description Framework (RDF) datastore. This proved very successful and this Testbed experience is already feeding into the OGC GeoSPARQL Standard roadmap. Vector data for Australia’s Level 1 Statistical Meshblocks and Hydrological Catchments were converted to DGGS RDF data with the DGGS Cell-ID as the predicate (i.e primary index) for the data. The OGC API - Features end-point presented this data as either JSON Linked Data (JSON LD) - using the DGGS zone -ID as the only representation of geometry, or as GeoJSON with the DGGS library generating vector geometries on-the-fly as required.

Participants started with an expectation that the Testbed-16 thread would deliver 'a simple application'. That participants were able to stand up an application delivering native DGGS vector and earth observation capability to users of both traditional Geographic Information Systems (GIS) clients and to native DGGS clients reinforced the versatility of DGGS and underscored its promise to deliver rapid multi-disciplinary analyses. Systems based on DGGS have been shown to have the characteristics of a chameleon that can acquire the character of both vector GIS systems and of earth observation systems. This means that both raster and vector data can be served through either raster or vector or DGGS native services. In its native form, DGGS also offer additional analytical versatility that is not present in either of these.

2.4. Overview of recommendations

Testbed participants documented future tasks in the following areas:

  1. Maturing DGGS Reference Library Implementations to bring them into conformance with OGC Topic 21 v2.0 (Maturing DGGS Reference libraries to meet community & future testbed needs);

  2. Drafting and elaboration of OGC APIs for DGGS (OGC API(s) for DGGS);

  3. Exploring the opportunities and limitations of DGGS driven analytics (DGGS processing opportunities);

  4. Implementation of OGC Registries for DGGS Implementations and DGGS enabled data services (The evolution of the OGC DGGS Registry);

  5. Targeted DGGS Interoperability Experiments (Opportunities for DGGS API in Interoperability Experiments).

2.5. Document contributor contact points

All questions regarding this document should be directed to the editor or the contributors:

Contacts

Name Organization Role

Byron Cochrane

OpenWork Ltd

Editor

Robert Gibb

Manaaki Whenua Landcare research

Editor

Matthew Purss

Pangaea Innovations Pty. Ltd.

Editor

Adrian Cochrane

OpenWork Ltd

Contributor

Nicholas J. Car

SURROUND Australia Pty Ltd

Contributor

Andrea Aime

GeoSolutions S.A.S.

Contributor

2.6. Foreword

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

3. References

The following normative documents are referenced in this document.

4. Terms and definitions

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard OGC 06-121r9 shall apply. In addition, the following terms and definitions apply.

● Coordinate operation

A process using a mathematical model, based on a one-to-one relationship, that changes coordinates in a source CRS to coordinates in a target CRS, or that changes coordinates at a source coordinate epoch to coordinates at a target coordinate epoch within the same CRS.

SOURCE: ISO 19111:2019 Referencing by coordinates

● Coordinate conversion

A coordinate operation that changes the coordinates in a source CRS to coordinates in a target CRS based on the same datum.

Note 1 to this entry This does not represent a change to the coordinates of the described feature, but rather a different representation of the same coordinate.

Source: SOURCE: ISO 19111:2019 Referencing by coordinates

Examples
  • Change Geographic coordinates (Latitude and Longitude) to Map Projection (Easting and Northing)

  • Change units from feet to meters

● Coordinate transformation

A coordinate operation that changes coordinates in a source CRS to coordinates in a target CRS in which the source and target CRS are based on different datums.

SOURCE: ISO 19111:2019 Referencing by coordinates

Examples
  • Change from GDA94 to GDA2020

  • Change from AMG66 to MGA94

● DGGS RS

'DGGS Reference System' a Reference system using zonal identifiers with structured geometry as described by the UML diagram in Figure 1

Fig core ReferenceSystemUsingZonalIdentifiersWithStructuredGeometry
Figure 1. Referencing by zonal identifiers with structured geometry
● DGGS RS provider (DGGS RS provider service)

Software library that processes DGGS RS definitions to create zonal identifiers and define their geometry.

Notes
  • a DGGS RS provider may be able to be used iteratively to provision a complete DGGS RS.

  • a DGGS RS provider service is a DGGS RS provider set up to operate in a web service architecture.

  • most DGGS software libraries available today are at the very least DGGS providers

  • none of the DGGS provider libraries identified in our stock-take (Table 1) support DGG_ReferenceSystem or MD_ReferenceSystem. 19170-1 is establishing a template/benchmark for what should happen.

Example
  • DGGRID is a DGGS RS provider that needs to be used iteratively to provision a complete DGGS RS, and

  • DGGRID is a command line library that would need further configuration to operate as a DGGS RS provider service.

● DGGS RS navigator (DGGS RS navigator service)

Software library that processes topological queries based solely on 'ZonalIdentifiers' as specified by the 'DGGS Core::ZoneQuery' interface.

Notes
  • a DGGS RS navigator service is a DGGS RS navigator set up to operate in a web service architecture.

  • Normal geometry operations: since a Cell has the behavior of Geometry as specified in ISO 19107, Cell.representativePoint and 'Cell.boundary` would be supported. For example:

    • if A and B are both ZonalIdentifiers then the DGGS RS navigator operation A.contains(B) returns a boolean.

    • Other operations in zoneQuery include all the DE-9IM operators as well as parent, child, sibling, parentOf, childOf, siblingOf and two 1D operators relativePositon and relatePosition.

    • ZoneQuery also supports operations spanning a specified number of refinement levels. So effectively queries involving grandchildren, cousins once removed etc can all be processed by adding a levels parameter to the child, sibling etc.

Examples
  • rHEALPix is a DGGS RS navigator as well as a DGGS RS provider.

  • H3 is also a DGGS RS navigator as well as a DDGS RS provider.

  • DGGRID is not a DGGS RS navigator.

  • In both libraries the navigator functions would need a wrapper to comply with the nomenclature and syntax in ZoneQuery.

● DGGS datastore

persistent storage for observation values assigned to zonal identifiers

Notes
  • each DGGS RS specifies a single geometry for their zones (cells).

  • all geometry types present in non-DGGS systems map onto collections of DGGS zones (cells).

  • there are three forms that collections of zones can take: single zone, arrays of zones, and ordered arrays of zones, where the ordering indicates a zone connectivity.

  • each element of a collection is a ZonalIdentifier.

● DGGS RDF datastore

storage uses ZonalIdentifiers as subject or object to represent a region of space-time and RDF predicates to associate the ZonalIdentfer(s) with observation values

● DGGS array datastore

observation values are stored using arrays in which the array is sorted by ZonalIdentifier, and may therefore define a function that relates ZonalArray offsets to array index

● DGGS raster datastore

observation values are stored as an image type sorted by lat,long (eg geotiff) and a function is defined to relate ZonalIdentifier with d/d-lat, d/d-long zone spacing

● DGGS analytics system

service providing spatial analysis of observations stored in a DGGS datastore

● DGGS quantization service

import process for converting observation data from non-DGGS format to DGGS format

Note

See OGC Topic 21 v2.0 Part 1 standard for detail

● DGGS Query/Broadcast Service

export process of converting DGGS format data to non-DGGS format

Note

See OGC Topic 21 v2.0 Part 1 standard for detail

● DGGS API

APIs to implement each of the above.

● trie

ordered tree data structure used to store a dynamic set or associative array where the keys are usually strings.

Note

Unlike a binary search tree, no node in the tree stores the key associated with that node; instead, its position in the tree defines the key with which it is associated; i.e., the value of the key is distributed across the structure. All the descendants of a node have a common prefix of the string associated with that node, and the root is associated with the empty string. Keys tend to be associated with leaves, though some inner nodes may correspond to keys of interest. Hence, keys are not necessarily associated with every node. For the space-optimized presentation of prefix tree, see compact prefix tree.

Note

See https://en.wikipedia.org/wiki/Trie

● zone

region of space-time

Note

In DGGS the zone is the fundamental unit of space-time. Each zone has a unique zonal identifier (ZoneID), and the zonal identifier has a defined position in a base CRS. The zone has geometry represented by a cell, and like all geometry, the cell has topology. Best practice is for the zonal identifier to be an encapsulation of both position and topology. The distinction between cell and zone was introduced in OGC Topic 21 v2.0 Part 1 both to encompass any spatio-temporal dimensionality, including 2D, 2D+Time, 3D & 3D+Time and to distinguish between the region and its geometry. See OGC Topic 21 v2.0 Part 1 standard for more detail.

Note

cell and cell ID, are only used in this document when referring to specific objects, classes or functions in existing software implementations.

4.1. Abbreviated terms

  • API Application Programming Interface

  • AusPIX Australian rHEALPix Reference System

  • CFP Testbed-16Call For Participation

  • DAPA Testbed-16 Data Access and Processing API for Geospatial Data

  • DGGS Discrete Global Grid System

  • GIS Geographic Information System

  • H3 Uber’s Hexagonal Hierarchical Spatial Index

  • HDF5 Hierarchical Data Format v5

  • JSON JavaScript Object Notation

  • OLAP Online analytical Processing

  • rHEALPix rearranged Hierarchical Equal Area iso-Latitudinal Pixelisation

  • TB-16 Testbed-16

  • TB16Pix Testbed-16 rHEALPix Reference System

  • URI Universal Resource Identifier

  • UTM Universal Transverse Mercator

5. Overview

Preface - provides the required Preface information such as copyright, warnings and license agreement.

Subject - introduces DGGS in the context of the TB-16 experiment.

Executive Summary - provides the Executive Summary of this report.

References - lists all normative references relevant to the outcomes of this experiment.

Terms and definitions - lists the key terms and definitions relevant to this report.

Overview - (this document) provides an overview and extended Table of Contents of this report.

DGGS and DGGS Reference System Selection - discusses the key criteria and justification for the selection of the DGGS libraries and associated DGGS Reference Systems used in this experiment.

DGGS API - discusses the context and API options for the DGGS thread and the definitions of the Features and Processes APIs that have been deployed.

Use Cases - presents and discusses the Use Cases employed to demonstrate the value of DGGS in the context of this experiment.

DGGS Server and API - presents and discusses the implementation of the DGGS Server, OGC API - Features endpoint, and the preparation of the data served for this experiment.

DGGS Demo Client - presents and discusses the implementation of the DGGS Client used in this experiment.

DGGS Enabled Data Services - presents and discusses the implementation of the DGGS-enabled Data Server, OGC API - Processes endpoint, and the preparation of the data served for this experiment.

Future Tasks - discusses Future Tasks and Activities that need to be undertaken to support the standardized implementation of DGGS and services that implement the DGGS API.

6. DGGS and DGGS Reference System Selection

6.1. Semantics for DGGS libraries and their association with the current DGGS draft standards

The new draft DGGS Abstract Specification (OGC Topic 21 v2.0 / ISO/DIS 19170-1) defines 1.) a DGGS Reference system as 'referencing by zonal identifiers with structured geometry', and 2.) a DGGS as a holistic system comprising:

  • A DGGS Reference system (DGGS RS);

  • A suite of DGGS Functions for:

    1. Quantizing data against the DGGS RS,

    2. Querying the topology of zones in a DGGS RS, and

    3. Interoperating with traditional W*S and OGC API systems.

Most existing DGGS libraries pre-date the new draft Abstract Specification (AS) and as a consequence they only partially fulfil the requirements of the draft AS. Furthermore, they are not structured neatly into modules that follow the above pattern. This has created confusion as to what comprises a DGGS. As such participants in this thread held diverse views of what constituted a DGGS. As the diversity was explored the need for some additional concepts or terms that reflected the different roles that a library might play in DGGS were identified. The participants also identified that some existing libraries supported a single DGGS RS, while others supported whole families of DGGS RSs. An analogy might be the difference between a library that locked in the Universal Transverse Mercator (UTM) Zones 3 projection as compared to a library that supports Transverse Mercator projections. With appropriate configuration parameters the library can support any UTM Zone - including UTM Zone 3. Following the structure outlined above, the participants distinguished between libraries that were DGGS RS providers - and those that were DGGS RS navigators.

6.1.1. DGGS RS provider

Providers support either a single DGGS RS, or configuration tools that can be used to support a family of similar DGGS RSs. For the DGGS RSs that they support, providers can generate ZoneIds and their associated geometry.

6.1.2. DGGS RS navigator

Navigators support the topological queries on zones based on ZoneIds. These are the usual Dimensionally Extended 9-Intersection Model (DE-9IM) functions such as within, overlap, contains etc.

6.2. The question of DGGS data

Early in the discussion between participants, the question was raised as to whether there was such a thing as DGGS data, and if there were, what would a DGGS datafile look like? For anybody coming into DGGS from a traditional GIS background, and thinking in terms of DGGS as a reference system, the obvious answer was no. For example, concepts such as World Geodetic System 1984 (WGS84) data or UTM 3 data have very little meaning. On the other hand, those participants heavily involved in DGGS thinking were convinced that DGGS data was a very real thing. Thinking about spatial data is typically in terms of its storage, and storage design is intimately bound to the form of the geometry being stored — Shapefiles, HDF5, GeoJSON, LASer (LAS) formatted files — are all solutions to the needs of storing geometries. Traditional reference systems are independent of geometry, and as a consequence the choice of reference systems is independent of the choice of data format.

By contrast, DGGS reference systems define their own geometry. This geometry is implied by the ZoneID. So, within a DGGS a geometry does not need to be explicitly provided as coordinates, and therefore does not need to be encoded in a traditional spatial data format. Instead, DGGS data only needs to record the ZoneId(s) associated with the feature, observation, or raster data zone (cell). This is very much like any other unique identifier associated with a list of attributes, and so DGGS data can be stored in many typical datastores. What makes it spatial data is the presence of the DGGS RS’s navigator functions that perform spatial topology operations using the ZonalID(s) in lieu of coordinate geometry. As a consequence, explicit read/write support for DGGS data in a DGGS library is not required. What is expected is handling of the quantization roles that are defined by the draft OGC DGGS Abstract Specification. These roles tell us the geometric relationship between a record and a ZoneId. They include a single coordinate (the zone centroid), or an area (enclosed by the zone’s boundary), or a tile.

6.3. DGGS libraries

A stock-take of DGGS libraries was performed and the following are the libraries found.

Table 1. DGGS Libraries
Name Author Cell geom Docs Repo Lang. Bind License DGGS RS prov.* Quant.* DGGS RS nav.* Interop.*

DGGrid

Kevin Sahr, Southern Oregon University

hex or tri

STCL

DGGrid on github

C++ cmd-line

AGPL 3.0

Y (config)

N

N

N

DGGridR (wrapper to use DGGrid in R)

Richard Barnes

hex or tri

STCL

DGGridR on github

R, C++

MIT

Y (config)

Y

N

N

H3 (built on DGGrid)

Uber

hex

Uber’s H3 index

H3 on github

C, java

Apache 2.0

Y

N

Y

N

OpenEAGGR

DSTL(UK) & RiskAware

tri or hex

Lit, Prog, Software

OpenEAGGR on github

C

LGPL v3

Y (config)

N

N

N

rHEALPix

Robert Gibb Manaaki Whenua

quad

Orig ellipoidal maths

rhealpixddgs-py on github

python

CC-BY 4.0 & LPGL for original code

Y (config)

N

Y

N

AUSPix (implementation of rHEALPix)

GA & CSIRO

quad

Loc-I & AusPIX

AusPIX on github

python

CC-BY 4.0 & LPGL for original code

Y

Y

Y

N

PYXIS

Perry Peterson Global Grid Systems

hex

n/a

commercial product

Y

Y

Y

Y

TerraNexus

Matthew Purss, Pangaea Innovations Pty. Ltd.

quad & tri

n/a

python

commercial product

Y

Y

Y

Y

…​ (add others here)

Note
* None of the libraries implements complete functionality in any of the four categories. Therefore the use of 'Y' in these columns indicates partial fulfilment. However, for the proposed purposes of TB-16 DGGS thread any gaps are trivial.

6.4. DGGS Libraries selected by the Testbed-16 DGGS thread

To demonstrate that the DGGS work undertaken was applicable to multiple DGGS, the decision was made to implement two DGGS, and the libraries chosen were H3 and rHEALPix.

  • H3: Use of H3 is resulting in the development of a significant user community and as a consequence H3 is the most mature in the sense of formal releases and bindings.

  • rHEALPix: Being used as AusPIX by the Australian Government’s Loc-I project. Also TB-16 thread participants were be able to pick up some of the additional code developed for AusPIX.

6.5. DGGS Reference systems selected by the Testbed-16 DGGS thread

H3 only supports one DGGS RS, so there are no further parameter choices to be made. The H3’s reference system is referred to as H3RS.

rHEALPix provides a number of hard-coded references systems, such as for covering spherical vs ellipsoidal earth models. For example, AusPix uses the default hard-coded WGS84 ellipsoidal reference system based on the zero meridian. Since Testbed-16 is developing solutions that may be demonstrated in a number of continents, the decision was made to choose a rotated version of the WGS84 that places all the corners of the initial cube in the sea. This reduces the area of land covered by the most distorted zones. This reference system as TB16Pix.

The code to provide TB16Pix, print the definition and export zone centers and edges for visualization in Google Earth is:

from rhealpix_dggs.projection_wrapper import *
from rhealpix_dggs.dggs import *
from rhealpix_dggs.ellipsoids import *

# define our WGS84 ellipsoid rotated so that all the corners of the cube lie in water
WGS84_TB16 = Ellipsoid(a=6378137.0, b=6356752.314140356, e=0.0578063088401, f=0.003352810681182, lon_0=-131.25)

# create our DGGS RS based on the defined ellipsoid
TB16Pix = RHEALPixDGGS(ellipsoid=WGS84_TB16, north_square=0, south_square=0, N_side=3)

# fyi print out the definition in full
print(TB16Pix)

# fyi print out the coordinates of the corners and centres of the cube's faces,
# note that the rHEALPix code doesn't support direct query of the  top level zones,
# so appropriate children are used
c = TB16Pix.cell(('O', 0)); print(my_round(c.nw_vertex(plane=False),9)) # Caspian Sea
c = TB16Pix.cell(('P', 0)); print(my_round(c.nw_vertex(plane=False),9)) # Sea of Japan
c = TB16Pix.cell(('Q', 0)); print(my_round(c.nw_vertex(plane=False),9)) # NW Pacific Coast
c = TB16Pix.cell(('R', 0)); print(my_round(c.nw_vertex(plane=False),9)) # Nth Atlantic
c = TB16Pix.cell(('O', 6)); print(my_round(c.vertices(plane=False)[3],9)) # Indian Ocean
c = TB16Pix.cell(('P', 6)); print(my_round(c.vertices(plane=False)[3],9)) # Australian Bight
c = TB16Pix.cell(('Q', 6)); print(my_round(c.vertices(plane=False)[3],9)) # Sth Pacific
c = TB16Pix.cell(('R', 6)); print(my_round(c.vertices(plane=False)[3],9)) # Sth Atlantic
c = TB16Pix.cell(('N', 4)); print(my_round(c.nucleus(plane=False),3)) # N - Nth Polar face
c = TB16Pix.cell(('O', 4)); print(my_round(c.nucleus(plane=False),3)) # O - Oriental face
c = TB16Pix.cell(('P', 4)); print(my_round(c.nucleus(plane=False),3)) # P - Pacific face
c = TB16Pix.cell(('Q', 4)); print(my_round(c.nucleus(plane=False),3)) # Q - Americas face
c = TB16Pix.cell(('R', 4)); print(my_round(c.nucleus(plane=False),3)) # R - Africa face
c = TB16Pix.cell(('S', 4)); print(my_round(c.nucleus(plane=False),3)) # S - Sth Polar face

As illustration the corners of the northern and southern zones are shown in the next two figures:

Table 2. TB16Pix Polar zones showing corners in water
TB16Pix Zone N corners TB16Pix Zone S corners