[Qgis-developer] Temporal data (was QGIS GRASS Plugin Upgrade Crowdfunding)

[Radim Blazek]

On Mon, Mar 30, 2015 at 11:17 AM, Nyall Dawson <nyall.dawson at gmail.com> wrote:
> On 30 March 2015 at 18:47, Radim Blazek <radim.blazek at gmail.com> wrote:
>> Hi again.
>
>>
>> I am getting convinced that the temporal data visualization support
>> should be added to QGIS core. A single time navigation toolbar
>> (from/to, start/stop, previous/next) and temporal support in data
>> providers (QgsVectorDataProvider::getFeatures,
>> QgsRasterDataProvider::block). That would allow simultaneous animation
>> of temporal data from various sources in different formats (time frame
>> defined by band, layer or attribute).
>>
>> There are already 3 plugins for temporal data management [1][2][3],
>> writing another one seems misconception and wasting of resources.
>
> +1 from me. I've also given this a lot of thought, and think that the
> best solution would be in QGIS core.
>
> I think porting the functionality from Time Manager would be a good
> start, but what I would really like to see would be for QgsDataDefined
> to be extended to handle animation support. This is already possible
> by a combination of scale_linear and Time Manager's current time
> expressions, but a better solution would be for
> QgsDataDefined/QgsDataDefinedButton to allow for properties of
> symbols/labels/composer items to be animated. For instance, smoothly
> vary the symbol size between 2 and 4 mm between these two datetime
> values.

I am not sure if QgsDataDefined is the right place. Isn't it too high level?

There are at least 3 possibilities how to store temporal vector data:
  1. single layer with timestamp (and possibly non unique id) field
(record per timestamp)
  2. single layer with multiple fields (field per timestamp)
  3. multiple sublayers (sublayer per timestamp)
These differences should be hidden in provider, I believe.

The timestamp is just another dimension and it should be added to
QgsFeatureRequest as a new member beside mFilterRect. If the format
allows to do geometry or value interpolation (i.e. 1. with id field or
2.), it should be done in provider.

The timestamp member would be added to QgsMapSettings and set by time
navigation toolbar.

This way, everything (e.g. table, feature info) may easily use current
timestamp (table updated on QgsMapSettings.timestampChanged signal,
feature info passing current timestamp to getFeatures()).

Radim


> I'd be willing to assist in coding this, but can't take the lead due
> to time constraints.
>
> Nyall