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

Nyall Dawson nyall.dawson at gmail.com
Tue Mar 31 02:21:51 PDT 2015


On 31 March 2015 at 20:05, Radim Blazek <radim.blazek at gmail.com> wrote:
> 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?

I wasn't proposing storing this data in QgsDataDefined - what I'm
thinking is that QgsDataDefined could be extended to allow for users
to control animations. I think this would fit well into
QgsDataDefined, as it's basically just another method for overriding
symbol/label/composer properties.

So the request/provider changes would be a prerequisite, but
QgsDataDefined/QgsDataDefinedButton would then be extended to allow
users to specify how the property will react to the time variable.
Think keyframes, tweening, etc...

Nyall



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


More information about the Qgis-developer mailing list