Applied opengeospatial#46 changes to GeoJSON-related requirement classes

- As outlined in opengeospatial#46 (comment)
- This addresses concerns about duplicated content in separate requirement classes raised by Carl Reed during OAB review
- This reflects the decision in opengeospatial/ogc-feat-geo-json#129 to not define a media type for FG-JSON separate from application/geo+json
- GeoJSON / FG-JSON requirement classes for zone data and zone lists were merged, with support for FG-JSON now a recommendation
- The `profile` parameter is introduced to negotiate the FG-JSON and DGGS-FG-JSON profiles of GeoJSON, which replaces the
  `geometry=quantized` and `geometry=quantized-zoneids` to select DGGS-FG-JSON.

core/requirements/requirements_class_zone_data_dggs_fgjson.adoc

@@ -16,21 +16,33 @@ requirement:: /req/data-dggs-fgjson/content
 ====
 [%metadata]
 identifier:: /req/data-dggs-fgjson/content
-part:: The Implementation SHALL support a `geometry` query parameter with a value of either `quantized` or `quantized-zoneids` allowing a client to request a DGGS-FG-JSON response.
-part:: Every 200 response of the server for zone data with the media type `application/fg+json` and a `geometry=quantized` (or `geometry=quantized-zoneids`) query parameter SHALL be an extended https://docs.ogc.org/DRAFTS/21-045r1.html[Features & Geometry JSON] (FG-JSON) document representing the vector features within the requested zone.
-part:: The JSON document SHALL follow the JSON Schema for FG-JSON, with geometry stored in a `dggsPlace` property mirroring the FG-JSON `place` schema and supporting all of the same feature types, but where `coordinates` use sub-zone indices (for `geometry=quantized`) or global textual zone identifiers (for `geometry=quantized-zoneids`) as described in later parts of this requirement.
+part:: The Implementation SHALL support zone data requests negotiating an `application/geo+json` media type combined with a `profile` query parameter with a value of `jsonfg-dggs`, `jsonfg-dggs-plus`, `jsonfg-dggs-zoneids` or `jsonfg-dggs-zoneids-plus` allowing a client to request a DGGS-FG-JSON response.
+part:: Every 200 response of the server for DGGS-FG-JSON zone data requests SHALL be an extended https://docs.ogc.org/DRAFTS/21-045r1.html[Features & Geometry JSON] (FG-JSON) document representing the vector features within the requested zone.
+part:: The JSON document SHALL follow the JSON Schema for FG-JSON, with geometry stored in a `dggsPlace` property mirroring the FG-JSON `place` schema and supporting all of the same feature types, but where `coordinates` use sub-zone indices (for `profile=jsonfg-dggs` or `jsonfg-dggs-plus`) or global textual zone identifiers (for `profile=jsonfg-dggs-zoneids` or `jsonfg-dggs-zoneids-plus`) as described in later parts of this requirement.
+part:: For `profile=jsonfg-dggs-plus` and `jsonfg-dggs-zoneids-plus`, the JSON document SHALL also include geometry stored in `geometry` or `place` using traditional coordinate reference system coordinates for compatibility.
 part:: The JSON document SHALL additionally contain a `dggrs` property set to the URI or CURIEs of the DGGRS of the response, which replaces the `coordRefSys` property and concept.
 part:: The JSON document SHALL additionally contain a `zoneId` property indicating the requested reference zone.
-part:: The JSON document SHALL additionally contain a `depth` property corresponding to the relative zone depth (as specified in the single depth format of the OGC API - DGGS `zone-depth` parameter for zone data retrieval), determining how coordinates are resolved from sub-zone indices (in the case of `geometry=quantized`), and as a result, their precision.
-part:: For `geometry=quantized`, the JSON document SHALL contain a `dggsPlace` property specifying geometry using local sub-zone indices ranging from 1 to the number of sub-zones within the reference parent zone at the declared depth, based on the deterministic sub-zone order of the DGGRS.
-part:: For `geometry=quantized-zoneids`, the JSON document SHALL contain a `dggsPlace` property specifying geometry using global textual zone identifiers (as defined in the DGGRS zone indexing reference system) at the declared depth.
+part:: The JSON document SHALL additionally contain a `depth` property corresponding to the relative zone depth (as specified in the single depth format of the OGC API - DGGS `zone-depth` parameter for zone data retrieval), determining how coordinates are resolved from sub-zone indices (in the case of `profile=jsonfg-dggs` and `jsonfg-dggs-plus`), and as a result, their precision.
+part:: For `profile=jsonfg-dggs` and `jsonfg-dggs-plus`, the JSON document SHALL contain a `dggsPlace` property specifying geometry using local sub-zone indices ranging from 1 to the number of sub-zones within the reference parent zone at the declared depth, based on the deterministic sub-zone order of the DGGRS.
+part:: For `profile=jsonfg-dggs-zoneids` and `jsonfg-dggs-zoneids-plus`, the JSON document SHALL contain a `dggsPlace` property specifying geometry using global textual zone identifiers (as defined in the DGGRS zone indexing reference system) at the declared depth.
 part:: When all spatial coordinates are dimensions of the DGGRS, the array of coordinates including the square brackets SHALL be replaced by the local index or global identifier of the sub-zone within which the coordinates are located.
 part:: When additional spatial coordinates that are not part of the DGGRS, such as elevation above ground for a 2D DGGRS, are needed to define the geometry coordinates,
 only the coordinates corresponding to DGGRS dimensions SHALL be replaced by the local index or global identifier of the sub-zone.
 part:: Only features fully or partly located within the reference zone SHALL be included.
 part:: For feature geometry intersecting the boundaries of the reference zone, the sub-zone within which the intersection is located SHALL be included,
-with a separate single `0` special sub-zone index (in the case of `geometry=quantized`) or a `null` value (in the case of `geometry=quantized-zoneids`)
+with a separate single `0` special sub-zone index (in the case of `profile=jsonfg-dggs` and `jsonfg-dggs-plus`) or a `null` value (in the case of `profile=jsonfg-dggs-zoneids` and `jsonfg-dggs-zoneids-plus`)
 representing all outside points before a point inside, after a point inside, or in between two inside points.
-part:: For geometry in two or more dimensions with an outside point (identified by a `0` sub-zone index for `geometry=quantized` or `null` for `geometry=quantized-zoneids`)
+part:: For geometry in two or more dimensions with an outside point (identified by a `0` sub-zone index for `profile=jsonfg-dggs` and `jsonfg-dggs-plus`, or `null` for `profile=jsonfg-dggs-zoneids` and `jsonfg-dggs-zoneids-plus`)
 and which is necessarily between two contour points, the portion of the zone edge(s) between the exit and entry point SHALL be considered inside of that contour.
 ====
+
+[recommendation]
+====
+[%metadata]
+identifier:: /rec/data-dggs-fgjson/geometry
+part:: The implementation SHOULD support a `geometry` query parameter allowing a client to choose how to return feature geometry.
+part:: The implementation SHOULD support a value of `geometry=zone-centroid` to request a representation where each feature is a zone intersecting the data, with the feature geometry of each feature being a Point geometry for the centroid of that zone.
+part:: The implementation SHOULD support a value of `geometry=vectorized` to request a representation where each feature corresponds to a feature of the data (sharing identical property values).
+part:: If a `geometry` value is not specified, the Implementation SHOULD return the representation closest to the native data.
+part:: If a requested geometry representation is not supported, the Implementation SHOULD return a 4xx HTTP error.
+====

core/requirements/requirements_class_zone_data_dggs_fgubjson.adoc

@@ -16,7 +16,7 @@ requirement:: /req/data-dggs-fgubjson/content
 ====
 [%metadata]
 identifier:: /req/data-dggs-fgubjson/content
-part:: The Implementation SHALL support a `geometry` query parameter with a value of either `quantized` or `quantized-zoneids` allowing a client to request a DGGS-FG-UBJSON response.
-part:: Every 200 response of the server for zone data with the media type `application/fg+ubjson` and a `geometry=quantized` (or `geometry=quantized-zoneids`) query parameter SHALL be a https://ubjson.org/[Universal Binary JSON] document representing the vector features within the requested zone.
+part:: The Implementation SHALL support zone data requests negotiating an `application/geo+ubjson` media type combined with a `profile` query parameter with a value of `jsonfg-dggs`, `jsonfg-dggs-plus`, `jsonfg-dggs-zoneids` or `jsonfg-dggs-zoneids-plus` allowing a client to request a DGGS-FG-UBJSON response.
+part:: Every 200 response of the server for DGGS-FG-UBJSON zone data requests SHALL be a https://ubjson.org/[Universal Binary JSON] document representing the vector features within the requested zone
 part:: The content of the UBJSON document SHALL follow all the of same requirements as for DGGS-FG-JSON described above.
 ====

core/requirements/requirements_class_zone_data_geojson.adoc

@@ -7,6 +7,7 @@
 identifier:: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-geojson
 subject:: Web API
 inherit:: <<rfc7946, GeoJSON>>
+inherit:: <<OGC21-045r1>> (optional FG-JSON dependency)
 inherit:: https://www.opengis.net/spec/ogcapi-dggs-1/1.0/req/data-retrieval
 requirement:: /req/data-geojson/content
 ====
@@ -16,10 +17,20 @@ requirement:: /req/data-geojson/content
 [%metadata]
 identifier:: /req/data-geojson/content
 part:: Every 200 response of the server for zone data with the media type `application/geo+json` SHALL be a https://datatracker.ietf.org/doc/html/rfc7946[GeoJSON] document representing the features, including their geometry and associated properties, for a single zone.
-part:: Unless otherwise specified by a prior arrangement (for example, a `crs` output parameter), the coordinate reference system SHALL be CRS84(h) in longitude and latitude (and optional height above the WGS84 ellipsoid).
+part:: Unless otherwise specified by a prior arrangement (for example, an output `crs` query parameter) or by negotiating an FG-JSON profile, the coordinate reference system SHALL be CRS84(h) in longitude and latitude (and optional height above the WGS84 ellipsoid).
 part:: Features whose geometry lie wholly outside of the zone geometry SHALL NOT be included in the response.
 ====
 
+[recommendation]
+====
+[%metadata]
+identifier:: /req/data-geojson/fgjson-profile
+part:: The Implementation SHOULD support a `profile` query parameter for zone data requests allowing to negotiate an https://docs.ogc.org/DRAFTS/21-045r1.html[OGC Feature & Geometry JSON] representation,
+where a value of `rfc7946` corresponds to RFC 7936 GeoJSON, a `jsonfg` value corresponds to a response conforming to FG-JSON, and a `jsonfg-plus` value corresponds to a response conforming to FG-JSON
+fully backward compatible with GeoJSON (e.g., including a GeoJSON geometry in the `geometry` field if geometry is otherwise provided in the FG-JSON-specific `place` property which supports extended
+geometry types and alternate coordinate reference system without prior agreement).
+====
+
 [recommendation]
 ====
 [%metadata]
@@ -42,14 +53,22 @@ part:: For datasets whose features have either a size (such as areal or linear f
 be omitted from the response based on the hierarchy level implied from the `zone-depth` relative to the requested zone.
 ====
 
+[recommendation]
+====
+[%metadata]
+identifier:: /rec/data-geojson/crs
+part:: For an FG-JSON response for which a `crs` query parameter is not specified, the CRS of the response SHOULD be consistent with the CRS of the DGGRS or the underlying geographic CRS (e.g., CRS84).
+part:: For an FG-JSON response for which a `crs` query parameter is specified, the `geometry` property SHOULD be used to return coordinates if the geometry does not require an extended FG-JSON type, since this constitutes a prior arrangement regarding the CRS of GeoJSON coordinates.
+====
+
 [recommendation]
 ====
 [%metadata]
 identifier:: /rec/data-geojson/geometry
 part:: The implementation SHOULD support a `geometry` query parameter allowing a client to choose how to return feature geometry.
 part:: The implementation SHOULD support a value of `geometry=zone-centroid` to request a representation where each feature is a zone intersecting the data, with the feature geometry of each feature being a Point geometry for the centroid of that zone.
-part:: The implementation SHOULD support a value of `geometry=zone-region` to request a representation where each feature is a zone intersecting the data, with the feature geometry of each feature being a (Multi)Polygon geometry.
+part:: The implementation SHOULD support a value of `geometry=zone-region` to request a representation where each feature is a zone intersecting the data, with the geometry of each feature being a (Multi)Polygon, (Multi)Polyhedron or (Multi)Prism.
 part:: The implementation SHOULD support a value of `geometry=vectorized` to request a representation where each feature corresponds to a feature of the data (sharing identical property values).
 part:: If a `geometry` value is not specified, the Implementation SHOULD return the representation closest to the native data.
-part:: If a requested geometry representation is not supported, the Implementation SHOULD return a 4xx or 501 "Not Implemented" HTTP error.
+part:: If a requested geometry representation is not supported, the Implementation SHOULD return a 4xx HTTP error.
 ====