Different DomainSet description per supported CRS

[jerstlouis]

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]

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]

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

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

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

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.