Open pvretano opened 2 years ago
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):
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.
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 https://github.com/opengeospatial/ogcapi-discrete-global-grid-systems/issues/72#issuecomment-2292568074 .
@pvretano @cportele
If you have a chance to glance at:
We'd like to extend FG-JSON with the ability to encode geometry coordinates as DGGRS sub-zone indices as a way to both:
"place"
, and would avoid including "geometry"
i.e., not attempt backward compatibility with GeoJSON)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.
Based on the latest discussions in https://github.com/opengeospatial/ogc-feat-geo-json/issues/129 I think we should do the following:
profile
query parameter with the values rfc7946
(the default), jsonfg
and jsonfg-plus
(GeoJSON compatibility). The media type would be application/geo+json
.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 listsgeometry
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
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:
where
andwhen
elements, DGGS can introduce new elements into GeoJSON to encode a list of relevant DGGS zone id's for example. Say something likedggsZoneIdList
.geometry
element can be NULL or some summary representation of the DGGS information encoded in thedggsZoneIdList
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 thegeometry
key.Any other participants in the discussion, please augment this issue with any points I may have missed.