Clarify Scaling for time dimension (or exclude non-spatial dimensions?)

[jerstlouis]

In Testbed-20 GDC @m-mohr pointed out that the expected behavior of scale-size=, scale-factor= for temporal dimensions is not clear at all.

In our implementation, we have not yet actually implemented resampling on the temporal dimensions (and currently only support >2D output for our own GNOSIS Map Tile format).

In OGC API - Tiles, - Maps and - DGGS, we have a concept of downsampling, but it only applies to the spatial dimensions, or in 2D + Time DGGS or the 2DTMS Annex J temporal extension proposal, to pre-determined partitioning of time.

Perhaps we should simply exclude temporal from "Scaling" (which was also proposed to be renamed to "Resampling")? We could rename the requirement class "Spatial Resampling"?

The capability could then be re-introduced with a function with more explicit semantic in Part 2?

cc. @joanma747

[fmigneault]

We could rename the requirement class "Spatial Resampling"?

Looks like a good idea to improve expectations and requirements from the scale-[...] parameters.

However, does that imply that a "Temporal Resampling" requirement class would be defined, for implementation that do want to support this feature?

[jerstlouis]

However, does that imply that a "Temporal Resampling" requirement class would be defined, for implementation that do want to support this feature?

I was thinking that this could be re-introduced in Part 2 as an explicit function that you can pass in properties=. We would leave it out of Part 1.

Additionally, this capability could be supported by pre-determined lower temporal resolution partitioning with a temporal DGGS or the 2DTMS Annex J approach to have pre-determined temporal partitions at different refinement levels. In both cases, this typically means having pre-calculated temporal overviews at e.g., hourly, daily, weekly, monthly, yearly resolutions.

[jerstlouis]

Following more discussions, it seems that we could define a resolution parameter allowing to specify the resolution for all dimensions of the responses (similar to subset), which could be expressed in meters per cell for spatial dimension, and using the ISO8601 terminology for temporal dimensions, or the units for other kinds of dimensions.

This parameter would be mutually exclusive with scale-factor, and mutually exclusive with scale-axes / scale-size for the same dimension. We will try to clarify how scale-factor, scale-size, scale-axes are applied for more complex cases such as irregular grids based on the interpretation in the WCS scaling extension, as much as possible.

[jerstlouis]

There was support at the Member Meeting in Goyang for a resolution parameter, and to provide informative rguidance on how to map all convenience parameters to the more general parameters.

[chris-little]

@jerstlouis Could you clarify the scope of the work here please? Are we talking only about regular grids, whether spatial or temporal or custom, or is the full domain/range of coverages, which includes irregular grids, or even not-gridded, such as point clouds being considered. For example, the TimeSeriesMarkupLanguage could be a useful response format, as it support both reguarl, piecewise regular and irregular time series.

[jerstlouis]

@chris-little The Topic 6 / ISO 19123(-1) definition of a Coverage includes anything representing the output of a function returning values for a direct position -- this includes regular / irregular gridded coverages, point clouds, feature collections, and pretty must just about any kind of geospatial data.

The output of OGC API - Coverages can be any representation of a coverage, so we are not talking only about irregular grids.

The resolution parameter we're proposing to add is most intuitive for regular grid output -- how it should be interpreted for non-gridded coverages need to be clarified in the requirements.

Nothing prevents the use of TimeSeriesMarkupLanguage as an OGC API - Coverages response format.