Conformance to OGC API features for non-WGS84 geometries

[rob-metalinkage]

since GeoJSON "geometry" property must be WGS84, then any CS geometries are likely to in other CRS and need to fit into other slots in the schema to remain compliant with OGC API features.

FG-JSON (in draft) provides an option with backward compatibility

https://github.com/opengeospatial/ogc-feat-geo-json

regardless, CS should very clearly state whether it is going to adopt this pattern, create a new one or explicitly break conformance to GeoJSON (and hence OGC API Features). Given the documentation so far, the last option does not seem to be intended, so it is probably critical to update schemas and examples to show how to maintain compatibility.

The saving grace is that the semantics of "geometry" is unspecified - only the data type range, so as an optional convenience it may or may not be present - however CS should perhaps focus solely on CRS explicit geometries.

[alexrobin]

FYI there is clause 22 in the current draft document that is a placeholder to define binding to FG-JSON for exactly that reason.

[rob-metalinkage]

noting that the current schemas are explicitly limited to WGS 84 via the definition of GeoJSON "title": "SamplingSurface", "allOf": [ { "$ref": "samplingSpatial.json" }, { "type": "object", "properties": { "geometry": { "oneOf": [ { "$ref": "https://geojson.org/schema/Polygon.json" }, { "type": "null" } ] },

[alexrobin]

Also, note that OGC API - Features Part 2 allows the use of other CRS in GeoJSON provided that the CRS is explicitly requested in the query string. This falls under the "prior agreement" clause of GeoJSON (see https://datatracker.ietf.org/doc/html/rfc7946#section-4).

We are now clearly referencing OGC API- Features Part 2 if handling of CRS other than crs:84/crs:84h is required. See https://opengeospatial.github.io/ogcapi-connected-systems/api/part1/standard/23-001r0.html#_dee014e9-fe1b-42e6-9fd6-d62ab3367e89