Consider include a Well Know Text description of the CRS

[joanma747]

(The origin of this entry is the CRS.DWG meeting in September 2020 but the need was discussed in CRS.DWG in Banff)

The idea is that CRS's evolve over time and the move. This means that the reference to a CRS id is not enough if you need that level of precision.
In practice providing an PROJ WKT entry (string) solves the problem as you can fully describe you CRS by yourself.

There is an emerging encoding alternative in JSON with some links documented here. But this will only work with we define the UML property as "any" and allow for a JSON object in the JSON encoding.

Here's what EPSG:32642 would look like in PROJJSON https://henzuru.io/v1/crs/EPSG/32642
https://proj.org/specifications/projjson.html
https://proj.org/schemas/v0.2/projjson.schema.json <-- openapi schema

[joanma747]

This issue is related to opengeospatial/ogcapi-features#333

[joanma747]

In addition to that epoch, or any other information (The rotation coordinates?) or specific realizations, to deal with the CRS. (@jerome). Lets work with the CRS group for guidance.

[joanma747]

for the WKT it will be easy to have a string than having to rely on a "non-OGC" specification.

[joanma747]

Review the UML encoding and make that JSON uses PROJJSON and XML uses WKT.

For the JSON encoding we will use JSON schema for the JSON encoding and WKT for the XML.

https://proj.org/schemas/v0.2/projjson.schema.json

PROJJSON is a JSON encoding of WKT2:2019 / ISO-19162:2019, which itself implements the model of OGC Topic 2: Referencing by coordinates. Apart from the difference of encodings, the semantics is intended to be exactly the same as WKT2:2019.

https://proj.org/specifications/projjson.html

[joanma747]

Now the wkt element of the CRS object is a PROJJSON object in the JSON encoding.