add temporal support

[opengeospatial]

add temporal support

[tomkralidis]

@cportele definition would follow CAT 3.0 Record csw30:TemporalExtent, i.e.:

         A type for specifying the temporal extent of the data
         item that a metadata record describes.  Omitting
         begin/end implies infinity in that direction.  The
         attribute "inclusive" can be used indicate whether
         the boundary value in included in extent or not.

so in feature collection metadata, something like:

"temporal_extent": {
    "begin": "2011-11-11T12:22:11Z",
    "end": "2012-11-24T12:32:43Z"
}

For temporal dimension definition for query, looking deeper this is simply an OpenAPI type definition to define as RFC3339/ISO8601.

[cholmes]

+1 - I'd love to see time be more of a first class citizen. I like putting most things in 'extensions', but I think it'd be better with time that the 'extension' is more to opt-out of time. Most features should at least have a published or updated time.

An awareness of time is a major advantage of WFS over just publishing a file to be downloaded. Should be easy to query just the latest updated features.

[cportele]

Having a capability to add the temporal extent, too, makes sense to me.

Could you provide more detail how "temporal dimension definition" is defined and how it should be provided, @tomkralidis ?

[rouault]

For the record, the STAC API (https://github.com/radiantearth/stac-spec/blob/dev/api-spec/spec.yaml) has a time parameter:

  time:
    name: time
    type: array
    description: An array of date-time strings that adheres to RFC3339 (for example 1985-04-12T23:20:50.52Z). One date-time in the array is the time to match. Two date-times represent a range. Any additional items in the array will be ignored.
    items:
      type: string
in: query

[tomkralidis]

@rouault good point. So probably a time parameter would be best here. The server would then know which field in their data is time enabled and process accordingly.

[rcoup]

@rouault out of curiosity (since it's not specified AFAICS)...

Two date-times represent a range

Is a "range" (>=t1 AND <t2) or (>=t1 AND <=t2)? We've found the former consistently easier to deal with. But other systems vary - eg. SQLs BETWEEN ... AND uses the latter.

[rouault]

@rcoup You know what... I censured myself, but I was going to propose in the #67 ticket to use this good old SQL-92 standard for advanced filtering since after all most serious backends are SQL compatible. From a OGR client point of view, this would avoid doing SQL --> whatever filtering solution WFS3 implements --> SQL. And even if the backend is not SQL compatible, no-SQL solutions generally offer tips how to convert from SQL to their syntax...
/me hiding in a cheese hole now.

[mclay]

@cportele i am interested in an WFS 3.0 implementation that also provides support for time slices as GML defines them

gml:AbtractTimeSlice

A timeslice encapsulates the time-varying properties of a dynamic feature - it shall be extended to represent a time stamped projection of a specific feature

including all the potential applications related to that concept including SNAPSHOT generation (i.e. WFS temporality extension 12-027r3). My question should we initially track the discussion it with this general 'temporal support' issue or do you prefer a dedicated one.

[cportele]

@mclay - I would suggest a separate issue. While the topics are clearly related, the other topics discussed above are relevant already for simpler cases than dynamic features as defined in GML.

[cportele]

Discussion during 2018-03-12 web-meeting: We want to be symmetric with the spatial aspect. Add the temporal extent and a time instant/range parameter (using a simple parameter, if ISO 8601 supports it). Clarify that the server will decide which properties to use for the selection when a bbox or time parameter is used.