search

opengeospatial / ogcapi-common

OGC API - Common provides those elements shared by most or all of the OGC API standards to ensure consistency across the family.
https://ogcapi.ogc.org/common
Other
45 stars 13 forks source link

CRS content negotiation #64

Open joanma747 opened 4 years ago

joanma747 commented 4 years ago

The presentation in the Architecture DWG with title "Dutch API Best Practices" - Linda van den Brink (Geonovum) (https://portal.opengeospatial.org/files/?artifact_id=90056, last slide) recommend to use headers for CRS negotiation. I believe OWS Common needs to consider that as another extension of the core.

In the GET request: desired CRS is indicated in the header, too: "accept-crs" In responses: CRS of query and response are sent in the header: "content-crs"

jyutzler commented 3 years ago

Recommend the "Future Work" label be added. Can this approach be evaluated in an OGC sprint or whatever?

jerstlouis commented 2 months ago

Now we have several OGC API standards supporting a CRS requirement class using the crs= query parameter to request a specific CRS. The Content-Crs: response header, but not Accept-Crs:.

These include: OGC API - Features - Part 2, OGC API - Maps - Part 1 and OGC API - Coverages - Part 1 (draft).

Since the response is quite drastically different and might surprise clients, especially because there is already requirements stating that the response will be in a particular CRS (CRS84 for Features , and the "native" aka storageCrs for Maps and Coverages), this Accept-Crs: mechanism might not be compatible with these requirements.

Can we close this issue as overcome by events?