Efficient format for representing vector data mapped to a DGG Hierarchy

[jerstlouis]

In the current draft OGC API - DGGS we introduce DGGS-JSON (and corresponding binary UB-JSON encoding) as a JSON schema for efficiently transmitting and storing data quantized to zones, which is best suited for raster data.

DGGS-JSON leverages the concept of sub-zones and a deterministic sub-zone order established by the selected DGGRS understood by the client/consumer and server/producer. Such a sub-zone order can easily be defined for any DGGH using fully nested cells (congruent sub-zones), and can also be defined for hierarchical grids like ISEA3H (however, we have yet to figure out how difficult it is to define such a sub-zone order for ISEA7H / H3 where the zones drift away from their ancestors at finer resolutions in a more complex manner).

Inspired from #46, past thinking, discussions with @geofizzydrink and recent feedback from @sahrk in OSGeo/PROJ#4211 (comment), I suggest also defining a format better suited for representing vector data contained within a particular parent zone (without the need to rasterize it), where the geometry coordinates are encoded as a single sub-zone index within that sub-zone. This format would also leverage the advantages of sub-zone order indices as I believe this uses the least possible number of bits to address the inside of a zone (e.g., for ISEA3H at a relative depth of 10 there are always 59,293 sub-zones for a hexagonal parent so a single 16-bit integer is needed; 32-bit goes down to a relative depth of 20 for 3,486,843,451 sub-zones). Since sub-zone orders are defined for an arbitrary relative depth, this allows for arbitrary precision of coordinates relative to the parent zone.

This format could be based on GeoJSON and/or Feature & Geometry JSON, with the following particularities:

• Identifying the "dggrs" as a property of the top-level object, just as in DGGS-JSON
• Identifying the "zoneId" of the reference parent zone as a property of the top-level object, just as in DGGS-JSON
• Identifying the "depth" (relative to parent zone identified in zoneId) at which the geometry is encoded in the top-level object (alternatively, we could allow for multiple depths as in DGGS-JSON, but that would make the format diverge more significantly from GeoJSON / FG-JSON)
• Coordinates are encoded based on the sub-zones they fall within at the sub-zone refinement level based on the selected relative depth (from parent zone), using either a [ {sub-zone index} ] to support an additional altitude coordinate, or if no additional coordinate is needed the inner [ ] could be dropped to be more compact and {sub-zone index} replaces the array of coordinates, where sub-zone index would be a value between 1 .. sub-zone-count.
• Geometry (e.g., (multi)line strings and (multi)polygons) crossing the boundary of the parent zone needs to introduce additional points at the boundary of the zone between the point outside the zone and the point inside, and all points outside (between two points inside or at the end of a LineString) are replaced by a single point identified with a placeholder sub-zone index of 0. This will allow identifying that point as artifically introduced by clipping against the zone geometry (not part of the original geometry) and facilitate re-assembling the geometry across multiple zones, also allowing to render polygon geometry without drawing the artificial edges at the zone boundary where geometry enters and leaves the zones. This clipping should be relatively easy to perform, simply clipping each segment of the line string or polygon contours against each edge of the parent zone of interest.
• We can also define a binary version of this based on UB-JSON for compactness.

I believe this would really work great.

We should discuss whether we want to define JSON and UB-JSON encoding requirement classes for this in the API.

@sahrk @geofizzydrink @allixender @perrypeterson @ldesousa @MichaelJendryke @rggibb @mpadillaruiz

[jerstlouis]

A couple initial examples partial snippets of what I'm now proposing to call DGGS-FG-JSON and drafting an encoding requirement class for in the API:

OpenStreetMap:

{
   "conformsTo": [
      "https://www.opengis.net/spec/json-fg-1/0.2/conf/core",
      "https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-dggs-fgjson"
   ],
   "dggrs": "[ogc-dggrs:ISEA3H]",
   "zoneId": "I0-1EFA652-D",
   "depth": "15",
   "type" : "FeatureCollection",
   "features" : [ {
      "type" : "Feature",
      "id" : 2305843009218664049,
      "geometry" : null,
      "place" : null,
      "time" : null,
      "dggsPlace" : {
         "type" : "LineString",
         "coordinates" : [ 13866054, 13899376, 13953688 ]
      },
      "properties" : {
         "highway" : "service",
         "name" : "Parliament Road",
         "name:fr" : "chemin Parliament",
         "access" : "no"
      }
   }, {
      "type" : "Feature",
      "id" : 2305843009218664071,
      "geometry" : null,
      "place" : null,
      "time" : null,
      "dggsPlace" : {
         "type" : "LineString",
         "coordinates" :
   ...

Natural Earth bathymetry in the Arctic:

{
   "conformsTo": [
      "https://www.opengis.net/spec/json-fg-1/0.2/conf/core",
      "https://www.opengis.net/spec/ogcapi-dggs-1/1.0/conf/data-dggs-fgjson"
   ],
   "dggrs": "[ogc-dggrs:ISEA3H]",
   "zoneId": "B0-5-A",
   "depth": "15",
   "geometryDimension": 2,
   "type": "FeatureCollection",
   "features": [
      {
         "type": "Feature",
         "id": 1,
         "properties": {
            "scalerank": 0,
            "featurecla": "Bathymetry"
         },
         "geometry" : null,
         "place" : null,
         "time" : null,
         "dggsPlace": {
            "type": "MultiPolygon",
            "coordinates": [
               [
                  [ 14355360, 14355250, 14355141, 14355032, 14354922, 14354813, ...

[jerstlouis]

Initial draft requirement class in:

https://github.com/opengeospatial/ogcapi-discrete-global-grid-systems/blob/master/core/requirements/requirements_class_zone_data_dggs_fgjson.adoc