-
Notifications
You must be signed in to change notification settings - Fork 0
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
Comments
Some questions to resolve here:
|
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 |
Suggest the following: Mandatory to support WGS84, or rather EPSG:4326. Use You can also support other projections. Use EPSG codes if available, and apply same rule as above. This rules applies to both |
Suggest the following for trs:
for both |
@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 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. |
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:
collection
extent
in acollection
data_query
object.referencing
in a CoverageJSON response.The text was updated successfully, but these errors were encountered: