Add ingestion of vector data

[danlooo]

One advantage of DGGS is the integration of both raster and vector data. Raster data ingestion involves just transforming the geographic coordinate of each pixel to DGGS cell index space.

API

• in: polygon list with vertices defining edges to outside and holes
• out: List of cell ids representing the given polygons

Challenges

• geographical coordinates inside a polygon are defined only implicitly by vertices of boundaries and holes
• The inverse (cell list to polygon) is trivial
• Topology might be altered after conversion to DGGS, e.g. rivers disconnected to the ocean or disjoint lines intersect, like in all rasterization (Zhou et al. 2020)
• concave polygons needs way more checks and add only little distortion (see here)

Applications

• Ingestion of geojson
• Raster data in which each pixel has a bounding box footprint

Other implementations

• H3 polygonToCells, Reimplementation in Rust, and Add additional modes for polygonToCells uber/h3#775
• S2 s2region_coverer
• open EAGGR ConvertWgs84PolygonAndAddToDggsShapes (not maintained for >7 years)
• not implemented in DGGRID or Healpix
• we can just rasterize the vector data in geographic space prior to DGGS conversion (already there)

Potential requirements

• All points inside a polygon, e.g. edge - epsilon, must be within a output cell list
• Two adjacent polygons with zero overlap must not have any overlapping cell ids (e.g. here)
• Just convert polygon vertices (inner and outer rings) like openEAGGR vs boundaries (linestrings) vs fill cells within a polygon like H3

[asinghvi17]

IMO the real use of DGGS for vector geometry is for pseudo-compressed rasterization and maybe tree acceleration. It could be useful but you wouldn't really want to operate on them, but it would accelerate zonal stats from a dggs back to the geometry. (But that can just be done via a reproject-to-plane and then do the usual planar rasterization)