On 31 March 2015 at 20:05, Radim Blazek <radim.bla...@gmail.com> wrote: > On Mon, Mar 30, 2015 at 11:17 AM, Nyall Dawson <nyall.daw...@gmail.com> wrote: >> On 30 March 2015 at 18:47, Radim Blazek <radim.bla...@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 _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer