search

opengeospatial / ogcapi-coverages

OGC API - Coverages draft specification
https://ogcapi.ogc.org/coverages
Apache License 2.0
22 stars 13 forks source link

Extensions #55

Closed pebau closed 4 years ago

bilts commented 4 years ago

It seems to be the convention elsewhere in the API to have URL parameters use lowerCamelCase. Is there a reason to break with this and use all caps?

bilts commented 4 years ago

Implementing the CRS, we have an issue in supporting CRSes where no EPSG code or similar is defined. We plan to allow this by allowing the server to accept things other than URLs for these parameters (e.g. Proj4 codes), but it's worth noting this issue in case others have it and it belongs in the spec, maybe a SHOULD statement?

pebau commented 4 years ago

CIS - the basis for OAPI-Coverages work - already provides something here: a "datacube" (ie: coverage with whatever number of dimensions) has exactly 1 CRS, represented - as per OGC convention - by a URL. In case a CRS does not exist (say, in EPSG) a CRS can be combined from existing CRSs / axes. This is also foreseen in ISO 19111-2, so in line with what's out there.

OGC operates a repository of CRSs which can return the definition ("resolve") the URL, but companies etc can just as well establish their own CRS resolver. Even inline transport in the metadata, for homegrown definitions such as supported by PROJ, is possible with this mechanism.

pebau commented 4 years ago

@bilts, re case: admittedly, I did not take enough care on this; as conventions are gradually getting stable I will be happy to do a final run once the rules are fixed.

Schpidi commented 4 years ago

Teleconference 20200205: Agreed to merge and restructure repository to follow OAPI-Features and to add a README.md to the extensions/ subdirectory.