By the way, although H3 is immensely popular, H3 (and S2) for that matter are more to be understood as point indexing and aggregation systems, less than true “raster-type” alternatives. rHEALPix on the other side, and ISEA-based DGGS (Snyder equal area projection), are certainly useful for gridded representation of continuous phenomena (like we use in GeoTIFF, NetCDF etc).
For example: H3 is an aperture 7 hexagonal grid with Gnomonic projection (NOT equal area), sports Numpy array support and has ports in like all the programming languages, that means H3 cell identifiers are understood across platforms, e.g. compute data in Python H3 and visualize in pure JavaScript in Kepler.gl or Deck.gl, without copying geometry (cell ID “contains” location and resolution/cell size). But then H3 cells are only “approximately contained within a parent cell” (for all hexagonal grids anyway), so hierarchical traversal is not fully “congruent” as would be with squares/rhombus or triangles.
There are a few core missions to suggest:
- make stuff easily installable
- make data conversion/binning best practices in code, “classic geo” (vector/raster) to DGGS and DGGS to geo
- storage of DGGS-indexed data (think table, index is cell ID plus data values at that “coordinate”) in cloud and “range” queries
- DGGRID has great grid construction functions (including ideal equal-area hexagons - like ISEA7H → Snyder equal-area aperture 7 hexagons), but currently only supports grid creation and binning of data, but no further geo-referenced location-, neighborhood- or grid traversal
- Dask DataFrame partitioned compute already easy, but could be more “spatially” aware
- can DGGS indexing systems be used/integrated with xarray semantics?
I am still working my way through the forum. Related works/discussions: