Open jerstlouis opened 1 month ago
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, ...
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 https://github.com/OSGeo/PROJ/pull/4211#issuecomment-2277064693, 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:
"dggrs"
as a property of the top-level object, just as in DGGS-JSON"zoneId"
of the reference parent zone as a property of the top-level object, just as in DGGS-JSON"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)[ {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 between1 .. sub-zone-count
.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.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