Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Constrain how crs, trs and vrs are described #30

Open
havardf opened this issue Nov 14, 2024 · 5 comments · May be fixed by #32
Open

Constrain how crs, trs and vrs are described #30

havardf opened this issue Nov 14, 2024 · 5 comments · May be fixed by #32
Assignees
Labels
core Issues common to all profiles

Comments

@havardf
Copy link
Collaborator

havardf commented Nov 14, 2024

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
Copy link
Collaborator Author

havardf commented Nov 14, 2024

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
Copy link
Collaborator Author

havardf commented Nov 14, 2024

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 havardf added the core Issues common to all profiles label Nov 14, 2024
@havardf
Copy link
Collaborator Author

havardf commented Nov 14, 2024

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 in crs_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
Copy link
Collaborator Author

havardf commented Nov 14, 2024

Suggest the following for trs:

"trs": "Gregorian"

for both collection and CoverageJSON

@havardf
Copy link
Collaborator Author

havardf commented Nov 14, 2024

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

@havardf havardf self-assigned this Nov 14, 2024
@havardf havardf linked a pull request Nov 19, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Issues common to all profiles
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant