OGC Testbed-16: DGGS and DGGS API Engineering Report

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:

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

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:

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.

Testbed participants documented future tasks in the following areas:

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

Contacts

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.

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:

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.

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.

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

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 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:

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