Qualify use of the term `resolution`

[jerstlouis]

As @strobpr pointed out, we need to be careful about use of the term resolution.

In OGC API - Coverages we use the term resolution to talk about:

• the distance between data points on a regular grid (the grid resolution) -- this usage is consistent with Topic 6 - Part 1 ("the single common distance between adjacent points on the axis, commonly called “resolution”), also consistent with usage in Topic 6 - Part 3.
• the native resolution of the data i.e., the smallest difference between observations or measurements that can be meaningfully distinguished (consistent with the GeoLexica definition of a sensor), whether the data is actually gridded or not (minCellSize / minScaleDenominator in OGC API - Common - Part 2 Collection Description),
• the query parameter resolutions allowing clients to resample the output data to a new resolution, whether the output is returned in a gridded or non-gridded coverage format -- This usage is consistent with the resolution-x parameter in EDR

We should clearly explain that:

• whether what is advertised as the native resolution (if advertised) and/or as the grid resolution corresponds to the suitability for purpose of the data based on the resolution of the original measurements depends on both the provenance of the data that was loaded into the OGC API - Coverages implementation (the original sensor resolution and any additional processing steps to produce that data) and any additional processing that the implementation itself may automatically perform,
• OGC API - Coverages does not specify the exact steps which must be performed when a client explicitly requests resampling with resolutions, or when the server automatically resample when the client does not explicitly request a particular resolution or native resolution with e.g., resolutions=Lat(),Lon() -- these are left up to the implementation to do the best thing it can (as agreed in Interpolation considerations #197 (comment)). The "resolution" of the grid for gridded output data will reflect this resampling, but the resampling steps might make the data unsuitable for purposes requiring data with full quality at that resolution (in particular if the data is being upsampled, or downsampled with lower quality methods).

[chris-little]

@jerstlouis Thank you for this clarity. resolution then could be applied to both Cartesian (x,y) and radial (r,θ) type coordinates, but not scale representations. Obviously, r and θ would each probably require specific rather than a single generic resolution.

[fmigneault]

OGC API - Coverages does not specify the exact steps which must be performed [...]

Regarding that point. It does make sense to let the server pick the best approach to deal with unseen use cases, unusual data, or allow flexibility for more optimal implementations. However, should there at least be recommendations about potential approaches or references? Could that increase opportunities of interoperability if most typical use cases are at least briefly covered? That might also help readers understand, through examples, what are the expected results, even if still at a relatively abstract level.

[jerstlouis]

@fmigneault Yes, definitely we should provide at least guidance on how to correctly address the most common use cases, and possibly recommendations.

Perhaps even requirements on things the servers should do or not do e.g., not do linear interpolation on categorical values.

[jerstlouis]

We've already added the recommendations regarding interpolation.

We only still need to review the document for the correct / consistent use of the term resolution.

[strobpr]

just make sure that you don't further confuse the wider community by circumscribing actual resolution with 'full quality at that resolution'. Resolution is connected with sample size and spacing (not in simple way), but sample spacing or pixel size are no guarantee for resolution. You can manipulate the spacing of a gridded data set at will, but its resolution will follow different laws. Just keep 'resolution' and 'spacing' separate and if spacing is discrete, talk about 'refinement_level' as foreseen in Topic21.