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

Hi again.

On Tue, Mar 24, 2015 at 10:04 AM, Sören Gebbert
<soerengebbert@googlemail.com> wrote:

Are there functions in time series implementation which need to be
called directly from the plugin or everything may be done just calling
t.rast.* modules?

Most of the temporal functionality is available through the temporal
modules. However some important algorithms (temporal re-sampling) are
available only in the Python framework. This is needed for time series
animation creation. Using the framework directly will speed things up,
because the module calls, the parsing and interpretation of the module
outputs can be avoided.

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] https://plugins.qgis.org/plugins/timemanager/
[2] https://plugins.qgis.org/plugins/multiview/
[3] https://plugins.qgis.org/plugins/temporalprofiletool/

Radim

Hi all,

If the long term aspiration of having support for temporal data is to
support NetCDF, HDF, GRIB, etc similar to:
http://blogs.esri.com/esri/apl/2015/03/11/dimension-explorer/
then probably we need to have more to it.

Martin has done a major update of the crayfish plugin which now supports
xdmf (a variation of HDF5) and soon we are looking to add animation feature
and more file support:
https://github.com/lutraconsulting/qgis-crayfish-plugin

Cheers,
Saber

-----Original Message-----
From: qgis-developer-bounces@lists.osgeo.org
[mailto:qgis-developer-bounces@lists.osgeo.org] On Behalf Of Matthias Kuhn
Sent: 30 March 2015 10:31
To: Nyall Dawson
Cc: qgis-developer; grass-dev@lists.osgeo.org
Subject: Re: [Qgis-developer] Temporal data (was QGIS GRASS Plugin Upgrade
Crowdfunding)

Hi

I think the very first step in this should be to add proper date (time)
support.
I don't know the state and requirements for raster layers, but for vector
layers I think right now time is converted with the edit types just for
visualization but internally it is passed around as string. It would be nice
to handle them as QDate(Time) internally.

For time-aware databases (postgres...) this should be straightforward.
For others (like shapefile?) we probably need to manage the datatype on the
project level but conversion should IMHO happen low-level directly in the
provider code so things like timezone handling and whatever else needs to be
done can happen exactly once when the data is read from the datasource or
saved to the datasource.

Filtering (from date ... to date ) should best be done on the
QgsFeatureRequest level (setFilterExpression should already be ready I
guess)

Best,
Matthias
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

--
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately
by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

Whilst reasonable care has been taken to avoid virus transmission, no responsibility for viruses is taken and it is your responsibility to carry out
such checks as you feel appropriate.

If this email contains a quote or offer to sell products, carry out work or perform services then our standard terms and conditions (which can be found at http://www.lutraconsulting.co.uk/downloads/Lutra%20Consulting%20Standard%20Terms%20and%20Conditions.pdf shall apply unless explicitly stated otherwise.

Saber Razmjooei and Peter Wells trading as Lutra Consulting.

Hi

not strictly related with timeseries visualization, but...
I was thinking to the time management abilities (and more) of the
Pandas python library as an abstracted data provider.
The main advantage are that on a pandas data frame, missing data can
be coded managed in a simply way.

Other than the complexity to match a data frame flexibility (m¡pandas
or numpy) with a reduce set of interactions of a data provider, there
would be also the problem to have pandas installed on osgeo4w that is
not simple at all!

regards, Luigi Pirelli

LinkedIn: https://www.linkedin.com/in/luigipirelli
Elance: https://www.elance.com/s/edit/luigipirelli/
GitHub: https://github.com/luipir
Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli

On 30 March 2015 at 13:37, Saber Razmjooei
<saber.razmjooei@lutraconsulting.co.uk> wrote:

Hi all,

If the long term aspiration of having support for temporal data is to
support NetCDF, HDF, GRIB, etc similar to:
http://blogs.esri.com/esri/apl/2015/03/11/dimension-explorer/
then probably we need to have more to it.

Martin has done a major update of the crayfish plugin which now supports
xdmf (a variation of HDF5) and soon we are looking to add animation feature
and more file support:
https://github.com/lutraconsulting/qgis-crayfish-plugin

Cheers,
Saber

-----Original Message-----
From: qgis-developer-bounces@lists.osgeo.org
[mailto:qgis-developer-bounces@lists.osgeo.org] On Behalf Of Matthias Kuhn
Sent: 30 March 2015 10:31
To: Nyall Dawson
Cc: qgis-developer; grass-dev@lists.osgeo.org
Subject: Re: [Qgis-developer] Temporal data (was QGIS GRASS Plugin Upgrade
Crowdfunding)

Hi

I think the very first step in this should be to add proper date (time)
support.
I don't know the state and requirements for raster layers, but for vector
layers I think right now time is converted with the edit types just for
visualization but internally it is passed around as string. It would be nice
to handle them as QDate(Time) internally.

For time-aware databases (postgres...) this should be straightforward.
For others (like shapefile?) we probably need to manage the datatype on the
project level but conversion should IMHO happen low-level directly in the
provider code so things like timezone handling and whatever else needs to be
done can happen exactly once when the data is read from the datasource or
saved to the datasource.

Filtering (from date ... to date ) should best be done on the
QgsFeatureRequest level (setFilterExpression should already be ready I
guess)

Best,
Matthias
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

--
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately
by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

Whilst reasonable care has been taken to avoid virus transmission, no responsibility for viruses is taken and it is your responsibility to carry out
such checks as you feel appropriate.

If this email contains a quote or offer to sell products, carry out work or perform services then our standard terms and conditions (which can be found at http://www.lutraconsulting.co.uk/downloads/Lutra%20Consulting%20Standard%20Terms%20and%20Conditions.pdf shall apply unless explicitly stated otherwise.

Saber Razmjooei and Peter Wells trading as Lutra Consulting.
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

On Mon, Mar 30, 2015 at 11:17 AM, Nyall Dawson <nyall.dawson@gmail.com> wrote:

On 30 March 2015 at 18:47, Radim Blazek <radim.blazek@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