opengeospatial/ogcapi-coverages

Different DomainSet description per supported CRS

Opened this issue · 7 comments

jerstlouis commented

As @cmheazel highlighted today while discussing CIS DomainSet issues, we probably want to be able to retrieve a separate DomainSet definition for each supported CRS. How will these be accessed?

pebau commented

who had that idea??? Thousands of EPSG CRSs, plus combinations with further ones...interoperability goodbye.

Also, you are already asking for details while (i) there is no explanation what the problem is and (ii) what the alternatives are, etc.

jerstlouis commented

@pebau I did, but that came out of discussions in the SWG today.
It's certainly up for discussion.

But wouldn't it be useful to know the name of the axes as well as their bounds for making subset request in other CRS than the native one?
Those resources can be dynamic of course to handle thousands of different CRSes.

pebau commented

@jerstlouis I have no idea what this all is about, there is no professional documentation mentioned that I could study, no reason given why it is important at all (beyond "wouldn't it be nice"). Overall, there seems to be fundamental lack of systematics in addressing topics.

jerstlouis commented

@pebau This is about figuring out how the CRS extension to OGC API - Coverages could work.

How to determine the name of the axes and the corresponding valid values for use with subsetting in a particular CRS, as usually provided by the DomainSet resource.

Sorry that you find a lack of systematics, but I believe we're all trying to do our best.

jerstlouis commented

So here is an idea which might work:

  • the domainset could be based on the storage/native/default CRS
  • the domainset resource (e.g. /coverage/domainset) could support the subset-crs= query parameter to select a CRS for which to report dimensions. A request like /coverage/domainset?subset-crs=[EPSG:3857] would then report the domainset in that CRS.

This is somewhat similar to a proposed solution for bands with different resolutions which also affect how the domainset gets reported.

jerstlouis commented

Review this in light of use of collection description extent, where the spatial extent is described both as CRS84 as well as in storageCrsBBox if storageCrs is not CRS84.

If implementing scenes, each scene can also have a different CRS.

jerstlouis commented

I believe that the storageCrsBBox in addition to the CRS84 bbox addresses the use case sufficiently and we don't need to do anything.