add resolution to collection temporal object

[tomkralidis]

Given various datasets with temporal extents provide multiple timesteps within an extent, does it makes sense to add an optional duration property (consistent with RFC3339)? Example below for model run with 3 hour time steps:

        "temporal": {
          "interval": [
            [
              "2020-05-23T00:00:00Z",
              "2020-06-02T00:00:00Z"
            ]
          ],
          "duration": "PT3H"
        }

[pebau]

this is already available in the spatio-temporal coordinate model of coverages, see the coverage examples provided with CIS.

[tomkralidis]

Thanks @pebau . I'm wondering about adding it here (mind you this would be valuable in common).

[pebau]

@tomkralidis: indeed, makes sense to have the general n-D case in addition to BBOX. Here is the central link: https://github.com/opengeospatial/ogc_api_coverages/blob/master/standard/clause_9_subset.adoc - but it does not talk about the CRS construction, that is, eg, in CIS.

[Schpidi]

20210303 Coverages SWG call: Related to #96, and also to the synchronization with Common part 2

[chris-little]

@pebau I get a 404 when trying to reach https://github.com/opengeospatial/ogc_api_coverages/blob/master/standard/clause_9_subset.adoc

[pebau]

@chris-little indeed, somehow shifting sands here...like the contents, the names keep changing as well:
https://github.com/opengeospatial/ogcapi-coverages/blob/master/standard/clause_9_coverage_rangesubset_subset_and_scaling.adoc

[jerstlouis]

SWG 2021-10-13: Duration could be an additional requirement module defined in Common. However the information can be computed by client from the interval definition (based on the first "overall" interval), so it is not essential to define in either Common - Part 2 or Coverages - Part 1.

Suggesting this issue be either moved as a future extension / requirement module for Common, or closed.

[tomkralidis]

related via OARec: opengeospatial/ogcapi-records#147

[chris-little]

@jerstlouis Adding a duration may be problematic, in that results may be unexpected by the requester. Generally, durations and intervals are not consistent for calendars (they do not use conventional arithmetic), but they are consistent for formal temporal CRSs that have only one UoM and are isomorphic to the number line.

Intervals, providing they are not 'subtracted', are safer.

[jerstlouis]

SWG 2022-01-12: We clarified today that this issue was actually about including a "resolution", rather than "duration". This overlaps somewhat with the resolution specified in the Domainset axis description. A "resolution" could be added as an (optional?) component of the extent Uniform Additional Dimensions defined in common, in addition to interval and crs.

[jerstlouis]

SWG 2022-02-09: In EDR, the additional values property was added separately from the interval allowing to define specific times or regular intervals at which data is available. The same appraoch could be done here. This should be a common building block defined in Common. Depending on the nature of how this is defined in Common, an implementation could either reference a conformance class defined in Common, or we would need conformance classes to define this in Coverages.

[pebau]

While I find this a very specific approach to a very specific question, I would not seriously object if the CIS schema is not changed. Options might be:

• in the metadata section of CIS
• in the Capabilities document equivalent

[jerstlouis]

@pebau This is about offering the possibility to include additional information in the collection description at /collections/{collectionId}. No impact on CIS.

The OGC API specifications do not have a single direct equivalent of the WxS services Capabilities document.
Instead it has different resources for different aspects:

• / The API landing page (Common - Part 1)
• /api (typically) The API definition (Common - Part 1)
• /conformance The conformance definition (Common - Part 1)
• /collections The list of collections (Common - Part 2)
• /collections/{collectionId} The detailed collection resource (Common - Part 2)

[pebau]

@jerstlouis ok, thanks for the clarification!

[jerstlouis]

SWG 2022-06-29: After reviewing the values syntax, we are realizing that the micro-syntax and the different ways that values is used might benefit from instead:

• Only allowing explicit list of values -- NOTE: In CIS DomainSet, this can also be specified in the coordinate field of IrregularAxes
• For the repetition mode, instead we would add repetitions and resolution properties to the extent and uad-extent schemas (this handles the different ValuesIsPoint vs. ValueIsArea as discussed in CIS#6
• The lower/upperBound syntax is not necessary, as it is redundant with the lower and upper bounds already defined

We can try to synchronize this change with the values recently added to OGC API - Tiles and inform the EDR SWG about this change, and discuss in Common.

NOTE: The purpose of this is to allow describing resolution,repetitions and explicit list of coordinates where data is available (which can be done in the CIS domainset), but as a simple extensions to Collection extent/extent-uad dimensions.

[jerstlouis]

Following feedback from last meeting, in PR #168, instead of values, grid is introduced as a member of extent dimensions, allowing to define either regular or irregular grids without introducing the ISO8601 micro-syntax. resolution and cellsCount (for regular grid) or coordinates (for irregular grids) are specified separately. This should make things easier for clients. It alaso avoids the redundancy with the intervals (an overall one, and optional ones for separate parts) already defined in the extent. The schemas should also feel more familiar to people familiar with CIS, while remaining significantly simpler. (NOTE: This still does not affect the CIS resources, it is only for the collection description extent).

By using grid instead of values, we also avoid a conflict with EDR, allowing to serve a collection as both EDR and Coverages. For EDR, coordinates are always quoted in values, even when numeric.

This approach follows what is being adopted in OGC API - Tiles (PR opengeospatial/ogcapi-tiles#124), where we also discussed this issue at length at the meeting last week.

@pebau @tomkralidis @chris-little
Could you please take a look to make sure we are all happy with this solution?

[tomkralidis]

@jerstlouis +1 for grid in extent dimensions. So then articulating a temporal resolution would look something like the the shorthand below?

extent:
    temporal:
        interval:
            grid:
                resolution: PT1H

[jerstlouis]

@tomkralidis grid is outside of interval, so rather:

extent:
    temporal:
        interval: [ [ '2011-11-11T12:22:11Z', '2011-12-11T12:22:11Z' ] ]
        grid:
            resolution: 'PT1H'
            cellsCount: 730

[tomkralidis]

ok, great. +1

[jerstlouis]

This issue has been resolved by PR #168.