Range subsetting details

[jerstlouis]

Should we have a recommendation or requirement that if the output format has a concept of field order, the order in the response follows the order in which properties were specified? e.g. should properties=B1,B2,B3 vs. properties=B3,B2,B1 return different results?

This would be useful e.g. to re-order the fields of a GeoTIFF response so that they automatically map to the right R,G,B channels by default when visualizing them in various tools.

Do we want to keep the possibility that data record fields be specified by index instead of by name? There can potentially be conflicts where numbers are used as band names (and possibly not 0-base-indexed).

Do we want to keep the possibility that 'all remaining' (*) fields be returned?

The latter two might be unnecessarily complicating the specification and implementations and has no corresponding concept in e.g. the Features properties parameter.

Beyond range subsetting with properties (derived fields):

It is becoming clearer in discussion with the DGGS (see this comment) and the Features group (see search proposal) that we can really define "search" querying capabilities common across the different OGC API access mechanisms using the same buildings blocks (e.g. filter, aggregation).

e.g. in addition to range subsetting, properties could be used to define derived fields as in DAPA. Aggregation could also partly be handled using the subset capabilities for the over part, whereas functions or operators as part of the derived field expressions could specify how to aggregate. We also already discussed re-using the common filtering extension in #103.

[jerstlouis]

SWG 2022-02-30: Agreed to include a requirement that the server returns the fields in the order requested for formats having a concept of field order.

[pebau]

This proposal is only halfways done - where & how is defined what the "right" assignment is? How can I override?

Further, it is extremely dangerous to simply ignore explicitly specified user parameters.

Therefore, STRONGLY objecting.

PS: "has no corresponding concept in e.g. the Features properties parameter": it is scary that not being in Features is already considered bad - completely neglecting that coverages have in part entirely different properties. Procrustes is calling?

[jerstlouis]

@pebau

If this:

how is defined what the "right" assignment is?

was in relation to:

so that they automatically map to the right R,G,B channels

what I meant is that the user (requesting client) knows what the right R,G,B channels are and wants to be able to specify a particular order.

How can I override?
Further, it is extremely dangerous to simply ignore explicitly specified user parameters.

The whole point of this issue was to allow the user / client to override the order, and require the server to give consideration to that order.

Considering this, do you still object? The specific changes can be found here:

d4c8cff

not being in Features is already considered bad

Not considered bad :) Just trying to facilitate integration of different types of data.

[pebau]

@jerstlouis I see; if the request specifies the output band order, isn't that exactly what the WCS Range Subsetting extension does?

[jerstlouis]

@pebau

6.4.2 GetCoverage response
The range subsetting parameter effectuates that only those range components mentioned are
returned to the client, and in the sequence requested (which may be different from the sequence of components in the range type definition of the coverage queried).

Yes, it seems that it is :) So this brings the OGC API - Coverages range subsetting conformance class closer to that extension. Which is why your strong objection came as a surprise.

[pebau]

@jerstlouis so obviously we are on the same page, I just got confused by the text. Glad to have convergence!