Incompatibility with Common - Part 2 for "interval"

[jerstlouis]

Aside from examples / implementations disagreeing with the extent JSON Schema, the specification of a temporal interval entry do not currently agree with Common - Part 2.

EDR allows more than two elements here, as a list of instants where data is available, or by specifying the "spacing" using start / end / spacing syntax, but in Features and Common, an interval entry is required to be exactly two values (a start and an end-time, with a null value indicating a half-bounded interval), and the first such entry is the overall temporal extent / interval of the collection, whereas additional entries are smaller time ranges where data is available.

Therefore [ "2011-11-11T12:22:11Z", "2011-11-11T14:22:11Z" ] has completely different meanings in EDR vs. in OGC API - Common, Features, Coverages, Tiles & Maps: in EDR it is interpreted at data at each of these precise time location, whereas in the others it is interpreted as data available between that start and end time.

I believe that agreement here is critical so that the same single OGC API collection could be accessed using different access mechanisms (e.g. Tiles, Coverages, EDR, Features, Map), as per the resolution of the Big Collections Discussion.

@chris-little @ghobona @cmheazel

[chris-little]

@jerstlouis, @ghobona @cmheazel : The approach adopted in the API-EDR is to use ISO8601 notation for the calendar-based temporal queries. This has been well established foa few decades. A comma separated list is a list. An interval is specified using /.

This is also consistent with WMS1.3 Annex C.2, and is specified as a consistent notation for other dimensions too.

CRS based temporal queries are specified using WKT notation, and again, a comma separated list is a list.

The API EDR primary use case is for web developers who are perhaps more likely to be familiar with ISO8601 than geospatial standards.

[jerstlouis]

@chris-little My main concern is not being able to offer the same collection as EDR + other OGC API (e.g. Coverages, Maps, or Tiles).
EDR uses concepts defined in OGC API - Common - Part 2 (the temporal "extent") but it works differently.

The EDR / ISO8601 notation approach to specifying intervals might have been better and more consistent with WMS 1.3, but this is a discussion that should have happened before OGC API - Features was approved (I suggest we try to understand whether that discussion happened or why this was not the outcome, as a way to improve this approach to defining common and consistent building blocks).

Consistency across the OGC API family is more important than anything else in my opinion.

[chris-little]

@jerstlouis I also think simplicity is important too. we are not trying to offer consistent and complex APIs.

[jerstlouis]

@chris-little I fully agree, but we cannot have simplicity without consistency, because it quickly becomes incredibly complex to support multiple divergent specifications, especially for something like this intended to work consistently.

The quest for simplicity really needs to be a team Common/Cross-SWG effort (and happen early in the specification process), and in my opinion for OGC to dedicate additional resources to ensuring both simplicity and consistency across the OGC API family would be really helpful.

[m-burgoyne]

@jerstlouis @chris-little I suggest we update the documentation to correct the inconsistencies, whilst I think intuitively [ "2011-11-11T12:22:11Z", "2011-11-11T14:22:11Z" ] defines a list of times I agree that we need to be consistent with the other OGC API's.

A single time would be:

"temporal": {
    "interval": [
        ["2021-03-12T00:30Z"]
    ]
}

A list of times would be

"temporal": {
    "interval": [
        ["2022-01-12T12:00Z"],["2022-01-12T15:00Z"],["2022-01-12T18:00Z"]
    ]
}

A time range with defined time intervals

"temporal": {
    "interval": [
            ["2022-01-14T09:00Z/2022-01-14T21:00Z/PT3H"]
    ]
}

And for date with time ranges with several defined intervals

"temporal": {
    "interval": [
            ["2022-01-14T09:00Z/2022-01-14T21:00Z/PT3H"],
            ["2022-01-15T00:00Z/2022-01-18T00:00Z/PT6H"],
            ["2022-01-18T00:00Z/2022-01-21T21:00Z/PT12H"]
    ]
}

Following the common specification

A time range would be:

"temporal": {
    "interval": [
            ["2022-01-12T12:00Z","2022-01-12T18:00Z"]
    ]
}

[m-burgoyne]

@jerstlouis @chris-little @ShaneMill1 @iandruska-ibl @pnovotny-ibl as discussed in the SWG meeting on 20-01-2022

A single time would be:

"temporal": {
    "interval": [
        ["2021-03-12T00:30Z","2021-03-12T00:30Z"]
    ],
   "values" : [
       "2021-03-12T00:30Z"
    ] 
}

A list of times would be

"temporal": {
    "interval": [
        ["2022-01-12T12:00Z","2022-01-12T18:00Z"]
    ],
    "values": [
        "2022-01-12T12:00Z","2022-01-12T15:00Z","2022-01-12T18:00Z"
    ]
}

A time range with defined time intervals

"temporal": {
    "interval": [
            ["2022-01-14T09:00Z","2022-01-14T21:00Z"]
    ],
    "values": [
            "R4/2022-01-14T09:00Z/PT3H"
    ]
}

And for date with time ranges with several defined intervals

"temporal": {
    "interval": [
            ["2022-01-14T09:00Z","2022-01-17T09:00Z"]
    ],
    "values": [
            "R12/2022-01-14T09:00Z/PT1H",
            "R4/2022-01-14T21:00Z/PT3H",
            "R4/2022-01-15T09:00Z/PT6H"
    ]
}

[jerstlouis]

@joanma747 @cmheazel @tomkralidis
This "values" proposal relates to opengeospatial/ogcapi-tiles#66 and opengeospatial/ogcapi-coverages#63 and could be a requirement module defined in Common.

[chris-little]

EDR API SWG 68 agreed the change and it will be in the V1.0.1 PR

[chris-little]

Fixed by PR#339