Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jerstlouis opened this issue Aug 27, 2024 · 6 comments
Open

Comments

@jerstlouis
Copy link
Member

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
Copy link

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
Copy link
Member Author

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
Copy link
Member Author

jerstlouis commented Sep 18, 2024

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
Copy link
Member Author

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
Copy link

@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
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Agreed; to be applied
Development

No branches or pull requests

3 participants