The paper compares two current implementations of Discrete Global Grid Systems as potential new data models for spatial data representation, integration, and analysis. It outlines suitability of such structures for spatial data modelling and GIS applications, as well as documents the core criteria necessary for their successful implementation. An experimental analysis is performed in order to determine the current state of their development and their practical applicability for data integration, analysis and visualization. The work concludes with a reflection on the current implementations compared to the industry standards and some future projections of geospatial analysis within Discrete Global Grid Systems framework.
Spatial data handling and integration has
become one of the prevailing needs in
geospatial analysis and computation. In the
modern digital context spatial data are
usually collected and stored as either raster
or vector representations, along with
attribute data for these spatial features
as a new model for spatial data
representation, integration and analysis
suited to the current data-rich environment
regular shaped polygons (Figure 1.0)
initially designed as a global reference
system for mapping and navigational
purposes
DGGS have also started to be used as a data
structure for consistent storage, reference
and analysis of spatial data and its attribute
information. DGGS suggest a different
approach for geospatial data handling that
allows interoperability of resources and
elimination of inaccurate and complex data
synthesis operations
documented and summarized in the Open
Geospatial Consortium (OGC) standard data
protocol
In addition, the unique topological
properties of regular shape tessellation
might also naturally suggest looking for new
forms of spatial analysis. The referencing
and indexing mechanisms, on the other
hand, provide reliable methods to access,
store and retrieve data. As a result, various
algorithms might integrate the existing
indexing system for data assimilation via the
refinement methods using the above
properties
analysis of two DGGS implementation: the
The following section outlines the methodology for comparing core data model requirements of the selected software libraries to the released OGC standards. It is very likely that certain requirements might not be met by either of the software, suggesting further advancing of DGGS packages. Both H3 and OpenEAGGR are open source software available via the
For the testing purposes both libraries were built directly from their source in their natural development environments. This step is necessary in order to gain access to the full list of available functionality, which might not be available through other language bindings. In particular, the H3 library is built from its source using CMake packaging software, Visual Studio development environment with integrated
using the MinGW compiler and Eclipse development environment. In addition, JavaScript binding for H3 and Python binding for OpenEAGGR libraries were also used in order to evaluate their flexibility and ease of use. Although not a requirement the libraries were also evaluated based on their availability for programing language bindings for the user’s convenience.
In this study the main focus is put on
hexagon shape structures due to their
availability on both platforms, as well as
their advantages in sampling, circularity,
packing and uniform connectivity properties
over the other regular shapes (e.g., triangles,
squares)
implementations compared to OGC standards is outlined in Table 1.0. The existing DGGS software provide a comprehensive approach for geocoding, indexing, addressing and processing geospatial data into discrete forms. Due to their hierarchical structures, positional uniqueness and discrete representation of spatial resolution, DGGS are gaining popularity and acceptance in the modern geospatial analysis and data integration.
A detailed technical analysis show basic functionality of DGGS for modeling Earth’s surface via hierarchical networks of equal area cells. Both libraries support hierarchical tessellation of regular polygons at increasingly fine resolutions up to a m2 and cm2 in areal size for H3 and
Riskaware, 2017). Each cell has a unique index and is accessible throughout the hierarchies. The given software also provides functionality to convert from latitude-longitude coordinates to DGGS indexes and vice versa referencing all cell centroids.
major properties of DGGS (criteria 11-12) (Table 1.0) it is important to mention that
and offset coordinate addressing structure
for hexagonal cell systems respectively.
Hierarchical addressing is based on the
lower resolution grid to find next
consecutive cell’s location of a higher
resolution, whereas offset addressing uses
fixed axis orientation and offset distances
from their origin to determine location of a
cell
that both implementations fail to meet the complete list of required criteria outlined by
4 5
Notes This requirement includes definition of conceptual data model of DGGS including reference frame (criteria 2-13) and functional algorithms (criteria 14-18) elements, which are partially fulfilled by each library. Guarantees the coverages of the entire globe. Each library fulfills the requirement for covering the entire surface of the earth.
Ensures positional uniqueness without overlapping cells. Theoretically, this requirement is met by both libraries; however practical application of OpenEAGGR fails to meet the requirement (see Figure 3.0). Forms a sequence of hierarchical tessellations at multiple spatial resolutions. Both libraries are capable of generating hierarchical grids at various resolutions.
A total surface area must be preserved throughout hierarchical tessellations. The following requirement is not met by OpenEAGGR due to the overlapping cells in criterion 3 and perhaps inconsistent geometry of the offset coordinate system.
Notes
DGGS cells must be formed of simple regular polygons. Both libraries
have met the requirement with H3 using mostly hexagons and
OpenEAGGR mostly hexagons and triangles (see criterion 8).
Any DGGS implementation will have equal area uncertainties of cells
caused by the factors such as converging calculation, the rate of
convergence or the precision of real numbers (e.g., ) used to calculate
DGGS cell geometry. H3 seems to omit such technical details for the
computational precision of equal area cells, whereas OpenEAGGR
summarizes some technical benchmarks in its prototype evaluation
framework
For each successive resolution equal area cells must be defined within the specified level of precision. Both libraries are constructed on the icosahedron with H3 using equal area hexagons and OpenEAGGR – hexagons and triangles. The only exception is that both hexagon grid libraries contain 12 pentagon cells centered at each icosahedron vertices and resolution. Pentagon cells are necessary in order to tile the sphere completely.
The initial partition of a sphere must be specified as a base unit polyhedron. Both libraries meet the requirement and use an icosahedron as a base.
Cell refinement methods and maximum number of refinements must be specified for each DGGS. H3 uses hexagonal aperture 7 grid partitioning method, whereas OpenEAGGR triangular aperture 4 and hexagonal aperture 3 cell partitioning.
A spatial referencing method for an assignment of a unique identifier (index) must be specified. H3 implements hierarchy-based indexing method, whereas OpenEAGGR uses hierarchical indexing for triangular and offset coordinate indexing for hexagonal cell systems.
A unique identifier must be assigned to each DGGS cell. Both libraries meet this requirement by assigning unique index to each DGGS cell using both hierarchical-based and offset coordinate indexing methods. The location of each DGGS cell must be referenced by the location of their centroids. Both libraries meet this property. It was tested by converting random latitude-longitude coordinates to a DGGS cell and vice versa. The new output coordinates were assigned to the cell centroids.
Quantization methods for assigning and retrieval of data to individual DGGS cells must be documented; however such functionalities are not supported at this stage of the development.
Methods for hierarchical and neighbourhood navigation must be provided. The H3 library is equipped with functions for navigating between different resolutions and neighbouring cells. The OpenEAGGR library, however, does not support the neighbourhood query, but only the navigation queries through hierarchy.
Methods for performing simple spatial analysis operations on the grids must be provided. At this stage of the development only OpenEAGGR library is equipped with spatial analysis functions, such as equals, contains, intersects, etc. for two DGGS shape objects.
Methods for receiving, interpreting and processing data queries by DGGS algorithms must be provided. The OpenEAGGR library supports integration with third party software, however those extensions are challenging to use due to the outdated technical support for the newer software releases.
Methods for integration, processing and transmitting data to external applications or web-based clients must be provided. The OpenEAGGR library also provides theoretical broadcasting functionality to external applications, however due to the limited technical support this property was not deployed in this study.
deliver a reasonable amount of functionality (Table 2.0) in order to meet basic DGGS requirements for operational capability of conversion, query and search across DGGS hierarchy.
Table 2.0: Outlines the list of available language bindings, software extensions and API functions for H3 and OpenEAGGR libraries.
Evaluation H3 OpenEAGGR Language Erlang C bindings Go C++
Java Java JavaScript Python OCaml PHP Python
R Software extensions Basic API functions
their development environments and must be executed via direct function calls from within. In other words, the libraries do not support a user friendly interface.
In addition, their practical applications for importing user data, performing spatial analysis as well as exporting and visualizing the end result still requires further development. The integration with other third party software should be more effortless, with up-to-date technical support.
seamless functionality of coordinate conversion to a DGGS cell indexes for individual point locations at different resolutions, which is also illustrated in practice (Figures 4.0, 5.0).
implemented by the H3 library, which allows performing basic distance and search queries in order to identify and generate neighboring hexagons within a desired distance from a cell of interest (Figure 6.0).
such functionality and only supports basic
parent-child cell relationship (Figure 7.0).
Furthermore, the developers indicate that
parent-child queries perform significantly
worse for hexagonal grids due to the
implemented offset coordinate indexing
system
advanced functionalities, such as filling polygon areas with hexagons as well as compressing them into more efficient representation (Figure 8.0).
not be classified as spatial analysis functions for performing operations and determining relationship between DGGS cells. The
support spatial analysis APIs for shape comparison of DGGS cells, linestrings and polygons with variety of available operations (Figure 9.0).
Visualization is not inherently available in the tested libraries. In other words, in order to visualize the output results the object or shape must be exported into one of the available file formats, such as GeoJSON or KML via OpenEAGGR APIs; however, this functionality might not be applicable to all DGGS shapes. If export is not possible the spatial data objects will remain stored in memory and could be accessed via direct memory calls as a workaround.
support built-in functionality for exporting shape geometries directly. As a result, a script for converting such data objects into
separately in order to visualize the output via third party applications such as Google
multiple techniques to study geographic phenomena by interacting with existing data related to a specific geographic location.
meaningful information with the help of computer processing and applications. Several problems might occur during such a chain of events, but integration of multiple data sources at once is an important aspect of the problem. DGGS set a benchmark for a more scalable and comprehensive data handling that can be distributed across different platforms and accessed via the web, and therefore have been investigated in detail in this paper.
Both H3 and OpenEAGGR software deliver basic functionality of DGGS, however cannot be classified as such due to the unfulfilled OGC requirements (Table 1.0). It was found that H3 library is missing some of the key functionality for assigning and retrieval of spatial data, data quantization as well as basic spatial analysis, query and broadcasting functionalities. The OpenEAGGR library is more successful with spatial analysis, data query and broadcasting implementations, yet still lacks support for data quantization and some essential properties of positional uniqueness and area preservation.
variety of language bindings available for integration with third party applications (Table 2.0), however not all of them are at the same level of development. In terms of the current progress, it also seems that the
development compared to the OpenEAGGR and has greater functional availability. New
implemented regularly, and connections
with other third party software continuously
explored for data query and broadcasting.
This includes Uber’s own operational needs
for dynamic optimization of ride prices, as
well as spatial decision making on a city
level
Therefore, all these components should receive additional attention in order to make them more practical and possible for average users to tailor for their specific needs. Once accomplished, however, it is very likely that DGGS will set new standards for geospatial analysis and open up new research prospects.