I was just recently whatching Nyall Dawson's video "QGIS 3.14 time handling and map animation demo". at min 47 (nyall dawson / youtube video min 47 ) things are getting interesting from my point of view.
While testing the "temporal controller" features I've had some confusing results when trying to implement the time dependent symbology approach shown in the video - imag_01 shows my results following the video-tutorial:
- data: a GPS track from a yacht race in the Adriatics. data acquisition interval is about 5 min
- point symbols (yellow): in the foreground are controlled by QGIS' temporal controller
- points (grey): in the background are non-temporal and displayed just for giving an overview temporal controller settings are:
- step width: 15min (= 0,25 hours)
- the displayed interval starts at
and ends at
2018-10-15 16:00:00 (see the values next to "Frame:" entry)
point size is depending on a temporal expression - just like in the video:
hour(@map_start_time - time_s_oesec") (see the expression in image_02)
@map_start_timeis the QGIS-internal variable - which should be equal to the Frame start value, i.e. '2018-10-15 15:45:00' in my example
time_s_oesecis a reference to the temporal field in my data - i.e. the location of the gps-tracking timestamp data (... values in the field time_s_oesec are stored without seconds in this example to keep things simple)
@map_start_time is the lower limit of the displayed time interval any timestamp within the interval is greater or equal
@map_start_time. Scaling the yellow points (according to Nyall Dawson's video) is based on the above-mentioned expression:
hour(@map_start_time - time_s_oesec).
image_01 shows my test-labels
- 1st line: GPS point field value e.g. "
time_s_osec: 15.10.18 15:50:00"
- 2nd line: current value of the map start variable e.g. "
@map_start_time: 15.10.18 15:45:00"
- 3rd line: "
@map_start_t* - time_s*: 1,92" that values should be negative due to the expresion
@map_start_time - time_s_oesecand they should NOT range from > 1 to > 2 within the defined interval
- 4.line: this is my check-value --> this value is the output from:
hour(to_datetime('2018-10-15T15:00:00')- "time_s_osec" ) where
'2018-10-15T15:45:00'is a fixed text which is transformed to hours based on QGIS datetime-format and should exactly correspond to the actual value of the variable @map_start_time
Obviously the expression in line 4 returns valid results - see/compare the following examples in image_01:
For the point at gps-time in the map 2018-10-15T15:45:00
time_s_oesec: 15:45 / result = -0,00 ... which is as expected
@map_start_time - time_s_oesecreturns a value of 2,0
for the point at gps-time in the map 2018-10-15T15:29:00
time_s_oesec: 15:29 / result = 0,27
@map_start_time - time_s_oesecreturns a value of 2,27
Summary: expressions in line 4 - which are based on the text-check-value
'2018-10-15T15:45:00' return positive values for gps-timestamps before "frame start time" 15:45 (since the GPS timestamp is less than the start time) and negative values after 15:45 since it is the other way round.
While the expression
hour(to_datetime('2018-10-15T15:00:00') - "time_s_osec" thus results to correct values the way the "temporal manager" handles
@map_start_time in that context is strange/faulty.
But... Is it worth a bug report ?
If needed I can provide test-data