[FEATURE][MESH] plug mesh layer to QGIS temporal framework #35466

vcloarec · 2020-03-30T17:55:04Z

Time handling in mesh layer

The time in a mesh layer is defined by :

a reference time provided by the data, the project or the user
each dataset is associated with a relative times
time extent is defined by the first time and the last time of all dataset

  Reference time :          AT
  Dataset 1 time            o-----RT------RT-----RT-----------RT
  Dataset 2 time            o---------RT------RT--------RT
  Dataset 3 time            o------------------------------RT-------RT----------RT
  Time extent of layer      o-----<--------------------------------------------->
  
  AT : absolute time (QDateTime)
  RT : relative time (qint64)

The class QgsMeshDataprovidertemporalCapabilities stores the reference time provided by the data and all the relative times of the dataset. This class has the ability to return dataset index from a dataset group index and a relative time since the reference time.
The reference time (can be different than the provider reference time) and the absolute time extent are stored in the class QgsMeshTemporalProperties

The temporal settings in the properties widget are only the reference time and the provider time unit:

The default reference time of the layer is set by (sorted by priority):

from the data provider if defined in data
from the project if defined
from current date with time 00h00
The user can change it if he wants.

Rendering principle

The 2D and 3D renderers access to the active dataset index from the layer with the time range stored in the QgsContextRenderer and in the Qgs3DMapSettings :
Relative time is calculated with difference between the time range of QgsContextRenderer and the reference time stored by QgsMeshTemporalProperties. The dataset index come from the QgsMeshDataproviderTemporalCapabilities that maps the relative time with dataset index.

Then data are brought from the provider with the dataset index.

Static dataset

There is also the possibility to set static dataset, that is to choose the dataset that will be rendered independently of the QGIS time controller. To do that the user can check the check box that is is at the bottom of the temporal page of the properties widget:

For now, as that was simpler to implement and allows to choose directly wanted dataset, the used can choose independently scalar dataset and vector dataset from combo boxes with the time associated to each dataset (relative time for data without reference time). If wanted, a unique time could be implemented, but that's could lead to inconsistently results with non synchronous dataset.
The static dataset settings are in the temporal page but can be easily put in the source page if wanted.

src/3d/qgs3dmapscene.h

src/app/3d/qgs3dmapcanvasdockwidget.cpp

src/core/mesh/qgsmeshdataprovidertemporalcapabilities.cpp

nyalldawson · 2020-03-31T03:50:38Z

src/core/mesh/qgsmeshdataprovidertemporalcapabilities.cpp

+  if ( datasetTimes.isEmpty() )
+    return QgsMeshDatasetIndex();
+
+  // If requested time is before the timestamp of the first dataset, return the first dataset


Not sure about this one -- shouldn't we return an "invalid" dataset instead so that nothing gets rendered?

With mesh layer, some datasets (for example, terrain elevation) are not really temporal and there is no reason to not display them for particular time step. But, MDAL doesn't provide way to distinguish "static" datasets and "dynamic" datasets. I used this workaround to always display such datasets, but, sure, it is not very clean... We can add the condition that the dataset group has only one dataset but it is not completely satisfying...

I would argue that this situation should be handled by users disabling the temporal option for those layers - that has the effect that the layer is always shown.

One option that is missing here is an equivalent of the raster temporal properties "fixed time range" mode, where a user can manually set a particular time range for that layer to shown within. It's in place to allow the animation framework to work with non-temporal-aware data sources (e.g. geotiff) where a user may have a set of multiple layers representing different time periods, and wants the animation to automatically switch them on or off if they fall within this fixed time range.

I think the mesh layers could also benefit from this option -- it's a "last resort" fallback for users allowing maximum flexibility for animations.

Set the whole layer static could be a solution for the user, but for mesh layer, there is not only one dataset group, we can have a terrain elevation dataset and many other dynamic dataset groups. I think also about the min/max dataset group...
More over, the problem is the same when the request time is greater than the time extent of the datasets. That is like this because the request of dataset is done with only one relative time value.
I wonder if it will not be better to request dataset with interval of relative time, and add an option to allow the display with the extreme dataset when the request time interval is before or after the time extent of the datasets?

discussed with Vincent:

implement MDAL_EXPORT bool MDAL_G_isTemporal( DatasetGroupH group );

add isTemporal() to QgsMeshDatasetGroup class

check the code that if group is not temporal, display always regardless of the time settings

as for "fixed time range" mode, I would propose to have it available (optionally) only for static mesh layers. for dynamic I do not see much sense

Ok, I'll defer to your superior knowledge of mesh internals here! 👍

src/core/mesh/qgsmeshdataprovidertemporalcapabilities.cpp

src/core/mesh/qgsmeshlayerrenderer.cpp

src/core/mesh/qgsmeshlayertemporalproperties.cpp

src/core/mesh/qgsmeshtracerenderer.cpp

src/core/qgsdataprovider.h

nyalldawson · 2020-03-31T04:03:01Z

Looking great! It's nice to see the temporal capabilities being brought into the 3d world too!

The static dataset settings are in the temporal page but can be easily put in the source page if wanted.

I think for consistency with raster layers this should be done

PeterPetrik · 2020-03-31T11:24:23Z

nice work! Already did some pre-review in the PR in Vincent's fork before official PR

nyalldawson · 2020-03-31T21:30:49Z

python/core/auto_generated/mesh/qgsmeshdataprovidertemporalcapabilities.sip.in

+
+    void clear();
+%Docstring
+Clears alls stored reference times and dataset times


Suggested change

Clears alls stored reference times and dataset times

Clears all stored reference times and dataset times

nyalldawson · 2020-03-31T21:32:15Z

python/core/auto_generated/qgsdataprovider.sip.in

+.. versionadded:: 3.14
+%End
+
+    virtual const QgsDataProviderTemporalCapabilities *temporalCapabilities() const;


Don't forget to update the existing raster and vector data providers to implement the const version too

and SIP_SKIP, no?

Yes, correct.

Thinking about this - it might be nicer to make the const version non virtual:

const QgsDataProviderTemporalCapabilities* temporalCapabilities() const { return const_cast< QgsDataProvider* >( this )->temporalCapabilities(); }

?

yes, very nice and smart!
But, a little cons, there will be no visibility of this const method in the derived class... easier to implement but maybe future issue ?

Yeah, I'm not sure. Something feels "off" about the double virtual method though...

Finally, as the compiler looks to no like very much this elegant way, I kept the first choice.

src/3d/qgs3dmapscene.h

nyalldawson · 2020-03-31T21:35:18Z

src/app/qgisapp.cpp

@@ -5470,6 +5471,15 @@ QgsMeshLayer *QgisApp::addMeshLayerPrivate( const QString &url, const QString &b
    return nullptr;
  }

+  // Manage default reference time, if not reference time is present by default in the layer -> assign one
+  if ( ! layer->temporalProperties()->referenceTime().isValid() )


Looks good for now! If there's more need for this in future we could consider adding a method to the layer temporal properties, something like "setDefaultsFromProject( QgsProject* project )" which we call here instead, but for now this is fine.

nyalldawson · 2020-03-31T21:39:07Z

src/core/mesh/qgsmeshdataprovidertemporalcapabilities.cpp

+  if ( datasetTimes.isEmpty() )
+    return QgsMeshDatasetIndex();
+
+  // If requested time is before the timestamp of the first dataset, return the first dataset


I would argue that this situation should be handled by users disabling the temporal option for those layers - that has the effect that the layer is always shown.

One option that is missing here is an equivalent of the raster temporal properties "fixed time range" mode, where a user can manually set a particular time range for that layer to shown within. It's in place to allow the animation framework to work with non-temporal-aware data sources (e.g. geotiff) where a user may have a set of multiple layers representing different time periods, and wants the animation to automatically switch them on or off if they fall within this fixed time range.

I think the mesh layers could also benefit from this option -- it's a "last resort" fallback for users allowing maximum flexibility for animations.

nyalldawson · 2020-04-01T22:58:10Z

Looks good to me -- apart from the typo and const note above I'm +1 to merge

vcloarec · 2020-04-02T03:51:54Z

Now, dataset group can be temporal or not.
Temporal dataset are displayed only if a dataset is contained in the current map temporal range (if not, take the last dataset before the time range except if it is the last one of whole the group, so for little time range between to dataset time, there are still a dataset displayed.. not sure explanation is clear, but works fine...).
Non temporal dataset groups (as terrain elevation, min/max group) are always displayed, whatever the map time range.

For now, non temporal are defined in the data provider when there is only one dataset because MDAL doesn't support this feature. Next version of MDAL will support it and the provider will be modified to take account.

nyalldawson · 2020-04-02T04:16:10Z

Looks good to me, but I can't comment on the mesh specifics. I'm +1 to merge, but let's give @PeterPetrik a final chance to look over...

PeterPetrik · 2020-04-02T06:40:19Z

@vcloarec there is failing test for mesh3d

1749   Loc: [../tests/src/3d/testqgs3drendering.cpp(454)]```

nyalldawson · 2020-04-02T23:06:46Z

@PeterPetrik time to merge?

nirvn · 2020-04-03T04:36:12Z

Nice to see the disjointed temporal stuff starting to come together :)

qgis-bot · 2020-04-03T06:21:32Z

@vcloarec
A documentation ticket has been opened at qgis/QGIS-Documentation#5226
It is your responsibility to visit this ticket and add as much detail as possible for the documentation team to correctly document this change.
Thank you!

github-actions bot added this to the 3.14.0 milestone Mar 30, 2020

vcloarec changed the title ~~[FEATURE][MESH plug mesh layer to QGIS temporal framework~~ [FEATURE][MESH] plug mesh layer to QGIS temporal framework Mar 30, 2020

vcloarec closed this Mar 31, 2020

vcloarec reopened this Mar 31, 2020

nyalldawson reviewed Mar 31, 2020

View reviewed changes

vcloarec force-pushed the QGIS_TIme branch from 96d19b6 to 68da213 Compare March 31, 2020 20:36

vcloarec requested a review from nyalldawson March 31, 2020 21:36

nyalldawson reviewed Mar 31, 2020

View reviewed changes

nyalldawson mentioned this pull request Apr 1, 2020

Postgres raster temporal API support #35511

Merged

vcloarec added 13 commits April 1, 2020 23:28

plug mesh layer to QGIS temporal framework

5e4a354

fix sip

674ca61

typo and minor fixes

705ea78

fix spelling

45b4d86

fix doc

1b64ac7

fix sip update...

931948a

assign project reference time from app and minor fixes

f73b1cf

check if render is temporal

611d36f

const temporalCapabilities()

7bb888c

link QgsTemporalController interface to Qgs3dMapCanvas

40266b3

sip update

5f992a0

const for temporalCapabilities

497b986

change relative time request approach and temporal/static dataset

4a19567

vcloarec force-pushed the QGIS_TIme branch from c661b0d to 4a19567 Compare April 2, 2020 03:28

move mesh layer static widget to source tab

98f8536

fix 3D rendering test

7f63678

vcloarec closed this Apr 2, 2020

vcloarec reopened this Apr 2, 2020

PeterPetrik merged commit 75ddf3c into qgis:master Apr 3, 2020

qgis-bot mentioned this pull request Apr 3, 2020

[FEATURE][MESH] plug mesh layer to QGIS temporal framework (Request in QGIS) qgis/QGIS-Documentation#5226

Closed

vcloarec deleted the QGIS_TIme branch April 4, 2020 14:52

timlinux removed the Changelog Items that are queued to appear in the visual changelog - remove after harvesting label May 22, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[FEATURE][MESH] plug mesh layer to QGIS temporal framework #35466

[FEATURE][MESH] plug mesh layer to QGIS temporal framework #35466

vcloarec commented Mar 30, 2020

nyalldawson Mar 31, 2020

vcloarec Mar 31, 2020

nyalldawson Mar 31, 2020

vcloarec Apr 1, 2020

PeterPetrik Apr 1, 2020

PeterPetrik Apr 1, 2020

nyalldawson Apr 1, 2020

nyalldawson commented Mar 31, 2020

PeterPetrik commented Mar 31, 2020

nyalldawson Mar 31, 2020

nyalldawson Mar 31, 2020

vcloarec Mar 31, 2020

nyalldawson Mar 31, 2020

vcloarec Mar 31, 2020

nyalldawson Mar 31, 2020

vcloarec Apr 2, 2020

nyalldawson Mar 31, 2020

nyalldawson Mar 31, 2020

nyalldawson commented Apr 1, 2020

vcloarec commented Apr 2, 2020 •

edited

Loading

nyalldawson commented Apr 2, 2020

PeterPetrik commented Apr 2, 2020

nyalldawson commented Apr 2, 2020

nirvn commented Apr 3, 2020

qgis-bot commented Apr 3, 2020

	Clears alls stored reference times and dataset times
	Clears all stored reference times and dataset times

[FEATURE][MESH] plug mesh layer to QGIS temporal framework #35466

[FEATURE][MESH] plug mesh layer to QGIS temporal framework #35466

Conversation

vcloarec commented Mar 30, 2020

Time handling in mesh layer

Rendering principle

Static dataset

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nyalldawson commented Mar 31, 2020

PeterPetrik commented Mar 31, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nyalldawson commented Apr 1, 2020

vcloarec commented Apr 2, 2020 • edited Loading

nyalldawson commented Apr 2, 2020

PeterPetrik commented Apr 2, 2020

nyalldawson commented Apr 2, 2020

nirvn commented Apr 3, 2020

qgis-bot commented Apr 3, 2020

vcloarec commented Apr 2, 2020 •

edited

Loading