Constrain how crs, trs and vrs are described

[havardf]

OGC-API Common and OGC-API EDR both are tolerant of various ways of specifying coordinate systems, leading to variations in the implementations, like:

• crs: WGS84
• crs: CRS84
• crs: EPSG:4326
• crs: GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS [..]

Since we do need to support more than one projection, the goal here is to constrain the syntax, so it can easily be autohandled by the client.

Perhaps though we could lock down trs to just one allowed value?

We need to tackle crs defined:

• At the root of a collection
• Inside extent in a collection
• Inside a data_query object.
• Inside referencing in a CoverageJSON response.

[havardf]

Some questions to resolve here:

• Can we lock down the value for extent/spatial/crs to epsg:4326?
• Can we lock down the value for extent/temporal/trs to Gregorian? If so, according to EDR standard should then this value just be omitted? If we should defined explicitly, what is the correct value for Gregorian calendar here?
• Must the vrs be in WKT format? And are there anyway any library support for this?

[havardf]

For vrs, is it possible to have an enumerated list of human readable strings? With clear documentation for how to handle each of the alternatives? Like pressure levels, msl, ...? Maybe not, according to https://docs.ogc.org/DRAFTS/19-086r7.html#col-temporal.

[havardf]

Suggest the following:

Mandatory to support WGS84, or rather EPSG:4326. Use epsg:4326 to represent this in crs, extent:spatial:crs and data_queries:*:crs_details:crs. Use relevant WKT string for WGS84 incrs_details:wkt`.

You can also support other projections. Use EPSG codes if available, and apply same rule as above. If no epsg code is available, then represent it in any user friendly you see fit.

This rules applies to both collection documents and CoverageJSON data response.

[havardf]

Suggest the following for trs:

"trs": "Gregorian"

for both collection and CoverageJSON

[havardf]

@mrauhala @Teddy-1000 The above suggestions for crs will not work sadly. The openapi spec for EDR says WGS84 unless otherwise specified, and WGS84 has reverse axis order to EPSG:4326.

We could say that WGS84 is mandatory, and you must use OGC:CRS84 as the string to represent this. For other projections use EPSG notation if available? I use CRS84 here, since OGC uses that name (http://www.opengis.net/def/crs/OGC/1.3/CRS84).

I see that the GeoJSON spec also states that its coordinate reference system is identical to OGC:CRS84. So in that sense, the naming is consistent and clear.

Seems like it is pretty common to talk about OGC:CRS84 and WGS84 almost interchangeably for geographic coordinate systems and also refer to EPSG for projected coordinate reference systems.