Support for compound CRSs or use service defined (in configuration) vertical reference system when no applicable compound CRS is available

[teezip]

Questions and enhancements needed

Questions and enhancements that maybe needed in Hakunapi:

• how to identify a vertical reference system along with horizontal one
  • OGC:CRSh explicitely defines: lon, lat, ellipsoidal-height (WGS84 ellipsoid)
  • there are some compound EPSG codes that define both horizontal and vertical CRS
  • what to do when no compound CRS id is available?
• how to configure the service (known ids, collection definition of CRS support, horizontal/vertical storage CRS, conversions etc.) when also Z coordinate should be supported
• what vertical reference systems should be used when only 2D crs is specified but the service should output also height
• for ellipsoidal geographic coordinates should only ellipsoidal height be allowed or also orthometric height when vertical reference system is not explicitely defined?

M coordinate is out of scope of this issue, however it should be handled in Hakunapi when outputting coordinates with different coordinate dimensions (XY, XYZ, XYM, XYZM)

• officially GeoJSON does not support M coordinates
• some formats do support and some use case may need it (ie. using M for distances from a start point along a polyline, related to linear referencing), supported output-coordinates: XYZM

Generic solution to support data with vertical coordinates

Any enhancements on Hakunapi must be generic and as standard compliant as practically possible.

Regarding to providing height RFC 7946 and OGC API Features : Part 2 are very clear (only) about the http://www.opengis.net/def/crs/OGC/0/CRS84h identifier. With WGS84 longitude, latitude ellipsoidal geographic coordinates only ellipsoidal heights are allowed. If ellipsoidal heights cannot be provided (ie. due to lack of coordinate conversions), CRS84h should not be supported, and such data is published according to the default CRS http://www.opengis.net/def/crs/OGC/1.3/CRS84 (WGS 84 longitude/latitude without height).

For other coordinate reference systems different interpretations may be needed.

The suggested generic solution:

• when referencing (ie. via the crs parameter) a registered compound CRS (with horizontal and vertical coordinates) height values naturally should be valid according to that coordinates system
• if registered compound CRS is not available and referencing a horizontal CRS, the service configuration decides how to deal with it
  • configurable choices when requesting feature items with the crs parameter
    • provide only XY-data (according to the axis order of the CRS)
    • provide XYZ-data (XY according to the axis order of the CRS, and Z containing coordinate values in a vertical reference defined in the configuration, configuration should contain id of a vertical reference)
  • storageCRS describes only a horizontal CRS, even if Z coordinates are provided
  • any vertical CRS is documented on the service documentation

In the future the support for compound CRSs may land on OGC API Features : Part 2 future extensions, but there is no roadmap about this known.

NLS of Finland specific notes when providing data with vertical coordinates

Note: short codes like EPSG:3067 used in this description, mapped to ids like http://www.opengis.net/def/crs/EPSG/0/3067 in OGC API Features services.

The default storage horizontal CRS is ETRS89 / TM35FIN(E,N) (EPSG:3067) and vertical CRS is N2000 (EPSG:3900) unless something other defined.

ETRS89 / TM35FIN(E,N) with N2000 height

• currently horizontal CRS id (EPSG:3067) is used in crs and other properties
• height data (when available on a collection) is assumed to be N2000 coordinates (EPSG:3900) without explicitely defining it by an API user
• in future also a new registered compound CRS is expected for the case ETRS89 / TM35FIN(E,N) + N2000 height, that shall be supported, when available
• currently available registered compound CRS EPSG:3903 (ETRS89 / TM35FIN(N,E) + N2000 height) shall NOT be used on OGC API Features services

ETRS89 / GKnn(N, E) with N2000 height

• horizontal CRS ids: EPSG:3873 to EPSG:3885 (13 projection zones)
• height data (when available on a collection) is assumed to be N2000 coordinates (EPSG:3900) without explicitely defining it by an API user

ETRS89 / UTM zones 34N, 35N and 36N (N, E) with N2000 height

• horizontal CRS ids: EPSG:3046 to EPSG:3048 (3 projection zones)
• height data (when available on a collection) is assumed to be N2000 coordinates (EPSG:3900) without explicitely defining it by an API user

WGS84 / ellipsoidal geographic coordinates

• EPSG:4326: lat, lon
• OGC:CRS84: lon, lat
• OGC:CRS84h: lon, lat, ellipsoidal-height (WGS84)
  • supported only if ellipsoidal height can be converted from N2000 storage heights to ellipsoidal heights in the service

WGS84 / Web Mercator projected coordinates (E, N), world between 85.06°S and 85.06°N

• EPSG:3857: E, N
  • what about heights, provide N2000 or no height at all? Service configuration decides?
  • normal use case for EPSG:3857 is to get data for web mercator tiles, is height needed at all in that case?

ETRS89 / ellipsoidal geographic coordinates

• EPSG:4258: lat, lon
• EPSG:4937: lat, lon, ellipsoidal-height (GRS80h)
  • this code not currently supported by OGCFeat services by NLS of Finland, but this code is available in the EPSG registry
  • supported only if ellipsoidal height can be converted from N2000 storage heights to ellipsoidal heights in the service

Standard requirements

GML

Not discussed here in details, but it's possible to define ad-hoc compound CRS like srsName="EPSG:3067, EPSG:3900" (in this case EPSG:3900 references to N2000 height in Finland).

GeoPackage

Not discussed here in details, but:

• possibility to store an ad-hoc compound CRS (with horizontal and vertical CRS ids) to the gpkg_spatial_ref_sys table when a registered compound CRS is not available
• an alternative for ad-hoc compund CRS is to use the crs_wkt extension

JSON-FG

Not discussed here in details, but as soon as the draft standard is finalized and published this might an alternative format to the standard GeoJSON.

It's possible to define ad-hoc compound CRS like

• ["http://www.opengis.net/def/crs/EPSG/0/3067", "http://www.opengis.net/def/crs/EPSG/0/3900"]
• or ["[EPSG:3067]", "[EPSG:3900]"], using CURIEs introduced in OGC guidance on Compact URIs

See also a sample from the draft containing epoch info too:

[
  {
    "type": "Reference",
    "href": "http://www.opengis.net/def/crs/EPSG/0/4258",
    "epoch": 2016.47
  },
  "http://www.opengis.net/def/crs/EPSG/0/7837"
]

Related issue on the JSON-FG repository:

• Question about coordRefSys and compound-CRS #102

GeoJSON

This is the main focus of this issue (at least in the context of OGCFeat).

RFC 7946 defines:

• 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.

OGC API Features - CRS

OGC API Features specifies in the Part 1:

• Unless the client explicitly requests a different coordinate reference system, all spatial geometries SHALL be in the coordinate reference system http://www.opengis.net/def/crs/OGC/1.3/CRS84 (WGS 84 longitude/latitude) for geometries without height information and http://www.opengis.net/def/crs/OGC/0/CRS84h (WGS 84 longitude/latitude plus ellipsoidal height) for geometries with height information.

Part 2 specification defines too:

• response CRS specified by the crs parameter
• query bbox CRS specified by the bbox-crs parameter
• the collection metadata resource
  • global (service) and collection specified lists of supported CRS identifiers
  • storage CRS published in storageCrs and storageCrsCoordinateEpoch
• response headers
  • An HTTP header named Content-Crs SHALL be used to assert the coordinate reference system used in the body of a response.

Note that all these parameters allow only one identifier, no compound CRSses supported currently.

Part 2 has also GeoJSON related clauses:

• GeoJSON normatively supports WGS 84 (without height: CRS84; with ellipsoidal height: CRS84h), but the "prior arrangement" provision allows other coordinate systems to be used.
• An explicit request by a client with a query parameter crs establishes a prior arrangement.
• If the requested coordinate reference system includes the vertical axis, the third-position element has to be interpreted according to that coordinate reference system, not as if it would be relative to the WGS 84 reference ellipsoid.

There are related issues on the OGC API repository:

• Question on GeoJSON and part 2 CRS #357.
  • 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.
• Add support for compound CRSs #864
  • With 3D data, there is often not a single, registered CRS available and a compound CRS has to be used combining a 2D CRS with a vertical CRS. This is currently not supported by Part 2.
  • The issue is inclued in the milestone Part 2, Version 1.1.0, still fully open.

[teezip]

Related EPSG registry changes: 2024.062

And Proj library changes: Database: update to EPSG v11.025