Add basic temporal handling support for vector layers by nyalldawson · Pull Requ...

nyalldawson commented on May 7

This exposes some basic temporal capabilities for vector layers:

• static time range for layer (to match raster layer possibilities), this sets a single static time range which applies to the whole layer. ALL features from the layer will be shown whenever the canvas time overlaps the layer time range
• "Single field with datetime": Allows selection of a single date or datetime field from the layer. Features will be shown whenever this field value is within the canvas time range
• "Separate Fields for Start and End Date/Time": Allows selection of start and end date/datetime fields from the layer. Features will be shown whenever the time interval calculated from these fields
  overlaps the canvas time range

(we should consider extending this in future, e.g. to add modes like "start time + fixed duration", "start time + duration from field", "start and end time via expressions", etc!)

Some known limitations/inefficiencies:

• currently only date/datetime fields can be used. This was done to simplify the format handling and avoid the need to worry about string fields with different datetime formats. In future we should
  allow selection of string fields and allow users to enter a custom datetime format string
• unlike the Time Manager plugin approach, the approach taken here is to rely completely on QGIS expressions and feature requests to do the filtering (Time Manager uses layer filter strings and attempts to set a native SQL filter syntax so that filtering is done on the backend). This is intentional, because it provides a unified filter approach regardless of the provider used (i.e. we don't need to worry about the different SQL syntaxes used natively by the different providers). The beauty of feature request expression compilation should mean that the QGIS expressions are magically turned into native backend queries, BUUUUUUUUUUUT... because we lack QGIS expression support for date time literals, we currently rely on the "to_datetime" expression function and coerce everything through strings. None of the expression compilers handle this function, so currently ALL
  filtering is done on the QGIS side. We need to add functions for optimised datetime literal creation, and then ensure that the different compilers correctly map these literals across to the backend
  filter syntax to allow all the filtering work to be done on the database side...

So currently, performance is much worse with large layers compared to Time Manager. (and the exposed feature set is smaller, e.g. no interpolation handling). But, the advantage is that we can use the native temporal framework and have vector layers animated alongside mesh and raster layers!