opengeospatial / coverage-implementation-schema

OGC Coverage Implementation Schema draft specifications
1 stars 1 forks source link

Clarifications on sub-setting in grid space #4

Open jerstlouis opened 3 years ago

jerstlouis commented 3 years ago

What defines the axis name of grid space? Is it implied that it is CRS:1, and the axes should always be named i and j, where the upper bound for j corresponds to the lower bound of lat in CRS84? Is support for the grid space axes required?

Should OGC API - Coverages conformance classes have any requirements and/or clarifications about this?

pebau commented 3 years ago

What defines the axis name of grid space?

<GridLimits srsName="http://www.opengis.net/def/crs/OGC/0/Index2D" axisLabels="i j">

...pick whatever axis names you like there.

jerstlouis commented 3 years ago

@pebau Right, I see that http://www.opengis.net/def/crs/OGC/0/Index2D does have the <axisAbbrev>i</axisAbbrev> and <axisAbbrev>j</axisAbbrev> so there is no confusion here.

...pick whatever axis names you like there.

The specifications are saying at the moment though that those names are defined by the CRS, so the server cannot just arbitrarily pick whatever names it likes.

I think we need to clarify the REQ_cov-subset-definition with the same type of requirement as the requirement D for scaling which clearly states where those axis names are defined per the CRS (in addition to being listed in the DomainSet).

But the main point here I think is we need to explicitly state whether support for indexing in grid space is a requirement for scaling and/or subsetting, and perhaps as well provide additional requirements about whether grid axes should be included in the domainset.

How about Index3D and Index4D? 3D adds k and 4D adds m, but if you have height + time, or only height, or only time, would one be preferably associated with a specific dimension? If not, if you have both would height be k and time m?

pebau commented 3 years ago

There was a corrigendum to all CIS/WCS for allowing free axis choice, which became necessary after a unilateral move of OGP. Unfortunately, OGC is grossly lagging behind publishing those (more than 1 year), maybe Stephan knows more about the status.

Index4D + height + time = 6D, believe this is not what you want.

jerstlouis commented 3 years ago

@pebau Are you saying that those 4D of Index4D never include height and/or time? Can't time and/or height also be indexed just like the spatial dimensions? Thanks!

pebau commented 3 years ago

yes, surely you can map time etc to Index, such as using Index4D and calling axes "Lat Long h time" - you just have no uom and only integer coordinates.