add temporal support

[tomkralidis]

Woudc be valuable to add:

• temporal extent definition in feature collection metadata
• temporal dimension definition in feature collection to provide clients capability to temporally query features. (OpenAPI may allow for this already by design by specifying data type along with attribute query property)

[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 ?

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

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