Relationship between DGGS, GeoJSON and JSON-FG.

[pvretano]

The purpose of this issue is to capture the discussion about DGGS and GeoJSON in today's end-of-day briefing.
The discussion was concerned with the relationship between GeoJSON and DGGS and JSON-FG and DGGS and more specifically how DGGS information can be encoded into a GeoJSON or JSON-FG document.

The key points of the discussion were:

1. The DGGS SWG might consider taking the approach of JSON-FG to extend GeoJSON for DGGS information.
2. Like JSON-FG that has introduced the where and when elements, DGGS can introduce new elements into GeoJSON to encode a list of relevant DGGS zone id's for example. Say something like dggsZoneIdList.
3. The GeoJSON geometry element can be NULL or some summary representation of the DGGS information encoded in the dggsZoneIdList element. This is analogous to they way a 3-D building footprint geometry in JSON-FG can be projected to a 2-D representation and stored as the value of the geometry key.
4. This approach allows an existing GeoJSON clients to read the file. They will, of course, ignore the additional DGGS elements.
5. Clients aware of the DGGS extension elements, can read and make use of the DGGS information.

Any other participants in the discussion, please augment this issue with any points I may have missed.

[jerstlouis]

See these DGGS-(UB)JSON resources with GEBCO data packets for ISEA3H zone A6-0-E (level 1) at relative depth 11 (177,877 level 12 sub-zones):

• DGGS-JSON example (3.21 mb)
• DGGS-UBJSON example (1.53 mb)
• Python tool available to easily convert between JSON and UBJSON
• list of sub-zones in same order as the values of the array in those examples
• A compressed GeoJSON (6.07mb 7z'ed, 95.15 mb uncompressed) with the elevation as a property of zone features including the geometry (in ISEA planar projection), which can be visualized directly in QGIS (you can apply a graduated style based on the Elevation property, and/or show a label for the Zone ID and/or Elevation value)

In addition to a GeoJSON representation of list of zones that includes zone geometry, data values, sub-zone order (feature ID), it includes sample DGGS-JSON files which is an encoding specifically targeting DGGS data (not encoding zone geometry, for which DGGS libraries should already have a built-in understanding for efficient use of DGGS).

See also the GeoJSON and JSON-FG requirement classes of OGC API - DGGS.

[jerstlouis]

Now proposing to define an efficient DGGS-optimized encoding of vector data which is extending FG-JSON with the concepts of DGGRS, parent zoneId, relative depth and sub-zone order defined in DGGS-JSON, replacing coordinate pairs by a sub-zone order index. See #72 (comment) .

[jerstlouis]

@pvretano @cportele

If you have a chance to glance at:

https://github.com/opengeospatial/ogcapi-discrete-global-grid-systems/blob/master/core/sections/annex-c-examples.adoc#dggs-fg-json-examples

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

https://github.com/opengeospatial/ogcapi-discrete-global-grid-systems/blob/master/core/examples/3-osmOttawa-extract.dggsfgjson

https://github.com/opengeospatial/ogcapi-discrete-global-grid-systems/blob/master/core/examples/4-arcticBathymetry-extract.dggsfgjson

We'd like to extend FG-JSON with the ability to encode geometry coordinates as DGGRS sub-zone indices as a way to both:

• be more compact than coordinates, since it only needs to address within a local DGGRS zone (the common use case would only use this in "place", and would avoid including "geometry" i.e., not attempt backward compatibility with GeoJSON)
• have these same coordinates readily mapped to the DGGRS
• address the issue of data clipped to zones and identification of artificial segment by virtue of replacing all outside points by a single 0 sub-zone index

Feedback would be welcome on the best approach to integrate this "DGGS-FG-JSON" with FG-JSON in terms of conformance classes etc. I'll join the meeting in a few minutes in case there's some time to discuss some of this.

Thanks.

[jerstlouis]

Based on the latest discussions in opengeospatial/ogc-feat-geo-json#129 I think we should do the following:

• Merge the GeoJSON and FG-JSON requirements classes for zone data, as well as the GeoJSON and FG-JSON requirements classes for zone list, clarifying that the conformance declaration should list the FG-JSON conformance URIs if they support FG-JSON, and describing the profile query parameter with the values rfc7946 (the default), jsonfg and jsonfg-plus (GeoJSON compatibility). The media type would be application/geo+json.
• For the DGGS-FG-JSON and DGGS-FG-UBJSON requirements classes, replace the use of geometry=quantized and geometry=quantized-zoneids with new values for the profile parameter: profile=jsonfg-dggs and profile=jsonfg-dggs-zoneids, as well as jsonfg-dggs-plus and jsonfg-dggs-zoneids-plus. The *-plus ones would set both geometry as well as dggsPlace. The media types would also be application/geo+json and application/geo+ubjson.
• geometry would keep its possible values of zone-centroid, zone-region or none for the GeoJSON / FG-JSON representations of zone lists
• geometry would keep its possible values of zone-centroid, zone-region or vectorized for the GeoJSON / FG-JSON representation of GeoJSON / FG-JSON zone data. Clarify that any of the jsonfg-dggs-* profiles implies either zone-centroid or vectorized (the default depending on whether the data is of a raster or vector nature). The data must be DGGS-quantized for the dggsPlace member, and regular coordinates are used in geometry for the compatibility profiles. Use of geometry=zone-region with any of the jsonfg-dggs profiles shall result in a 4xx error.

cc. @geofizzydrink @cnreediii

[jerstlouis]

Closing this issue as this has been addressed from multiple angles in the OGC API - DGGS Candidate Standard.

• There are GeoJSON encodings requirement classes for both Zone data Retrieval and Zone Queries, where the profile query parameter is now used to request plain GeoJSON (the default), FG-JSON or FG-JSON compatibility profiles. For Zone data, the features can represent either actual features, or zones with associated properties if the data has been rasterized. For zone queries, the features always represent zones. Features representing zones can be centroid points, or zone regions (polygons or polyhedrons/prims depending on whether the DGGRS is 2D or 3D+). The optional geometry query parameter provides some client control over these options.
• The DGGS-FG-JSON requirement class (and the UBJSON binary variant of it) provides a DGGS-optimized way to represent the data, where the geometry points are quantized to zone of a particular refinement level. This information is stored in dggsPlace instead of place, supporting any FG-JSON geometry types simply by replacing coordinates by a local sub-zone index (profile=fgjson-dggs) or global zone identifier (profile=fgjson-dggs-zoneids). The -plus profile variants of these also includes GeoJSON-compatible geometry in geometry.