Question on GeoJSON and part 2 CRS

[heidivanparys]

RFC 7946 says (highlighting is mine):

4. Coordinate Reference System

The coordinate reference system for all GeoJSON coordinates is a
geographic coordinate reference system, using the World Geodetic
System 1984 (WGS 84) [WGS84] datum, with longitude and latitude units
of decimal degrees. This is equivalent to the coordinate reference
system identified by the Open Geospatial Consortium (OGC) URN
urn:ogc:def:crs:OGC::CRS84. An OPTIONAL third-position element SHALL
be the height in meters above or below the WGS 84 reference
ellipsoid. In the absence of elevation values, applications
sensitive to height or depth SHOULD interpret positions as being at
local ground or sea level.

So if I understand this correctly: if I would want to use the compound coordinate reference system http://www.opengis.net/def/crs/OGC/1.3/CRS84 + http://www.opengis.net/def/crs/EPSG/0/5799 (which does not have an EPSG code as far as I can see, let's say http://www.opengis.net/def/crs/EPSG/0/xyz for now) , and if my height expressed in EPSG 5799 is 7, I cannot use

{
  "type": "Feature",
  "id": "06141",
  "geometry": {
    "type": "Point",
    "coordinates": [
      54.8275,
      11.3292,
      7
    ]
  },
  "crs": {
    "type": "link",
    "properties": {
      "href": "http://www.opengis.net/def/crs/EPSG/0/xyz"
    }
  },
  "properties": {
    "prop1": "value1"
  }
}

but I could use

{
  "type": "Feature",
  "id": "06141",
  "geometry": {
    "type": "Point",
    "coordinates": [
      54.8275,
      11.3292
    ]
  },
  "properties": {
    "heightDVR90": 7,
    "prop1": "value1"
  }
}

But then if clients are following the recommendation "In the absence of elevation values, applications sensitive to height or depth SHOULD interpret positions as being at local ground or sea level", that is an issue.

❓ Should the standard say something about what is explained above? Is this part of the "prior arrangement" provision, referred to in the standard, thereby overruling that recommendation?

❓ What exactly does "prior arrangement" mean? Is that what is described in GJ2008, the The GeoJSON Format Specification of 2008? Or could it be any structure, as described in section 5.3 in Testbed-12 JSON and GeoJSON User Guide or in the (deprecated?) doc https://github.com/opengeospatial/architecture-dwg/blob/master/json-best-practice/deprecated/clause_7b-geometrical-dimension.adoc?

❓ Should the standard indicate more clearly that JSON encoding of geometries in coordinate systems others than http://www.opengis.net/def/crs/OGC/0/CRS84 and http://www.opengis.net/def/crs/OGC/0/CRS84h is not standardized? Perhaps with a reference to https://github.com/opengeospatial/architecture-dwg/tree/master/json-best-practice and/or Testbed-12 JSON and GeoJSON User Guide?

[cportele]

Meeting 2020-04-27: Identifiers do not have to be OGC CRS URI, but anyone can assign their own (persistent) identifiers for their CRSs. So, it is possible to use Part 2 with new compound CRSs, but of course these identifiers will in general not be understood.

And we seemed to remember that there is a mechanism for OGC CRS URIs for compound CRSs from their components, but we need to find a reference for that.

[heidivanparys]

I just want to clarify my question: My question was not so much on how to reference a (new) compound CRS (as the answer is about), but on the interpretation of the z values. In addition to that, I had a question regarding the (lacking) standardization of JSON encodings. See the 3 questions at the bottom of the original post.

[cportele]

but on the interpretation of the z values.

The interpretation will depend on the format. OGC API Features does not specify any requirement or recommendation how to interpret a coordinate without z value.

In addition to that, I had a question regarding the (lacking) standardization of JSON encodings. See the 3 questions at the bottom of the original post.

The "limitations" of GeoJSON are already discussed in Part 1. There have been discussions about standardizing / supporting JSON representations that go beyond the scope of GeoJSON (and thus are no longer GeoJSON), but currently there is nothing that is mature enough to mention/reference from a standard.

[nmtoken]

What exactly does "prior arrangement" mean? Is that what is described in GJ2008, the The GeoJSON Format Specification of 2008?

Putting aside for a moment what prior arrangement means it would perhaps be better to consider when prior arrangements should/could be made.

GeoJSON is defined by RFC 7946, and formally has no mechanism to use any CRS other than CRS:84 +/- height; the Pre-IETF GeoJSON Format Specification of 2008 is now obsolete (https://geojson.org/geojson-spec.html), and one should be careful when continuing to use it.

The normal expectation of anyone receiving a GeoJSON file should be that the data is in CRS:84. Using different media types can be of use to distinguish files conforming to the obsolete vs current standards when exchanged though a service/API, but there is a risk that data once received, will be misinterpreted.

In an open system (when anybody could get the data) then stick to the standard.

In a closed system (when everybody has some agreement) you are free to do what you want, you could just use a different CRS, or you could use a crs member, or you could do something else.

[cportele]

Meeting 2020-05-11: @cportele to check, if any wording should be clarified.