Temporal controller time frame is reset when changing step size

[anitagraser]

In Master, changing the step size in Temporal Controller resets the current time frame. The user therefore always loses the current temporal "position" and it's hard to get back since there is no way to jump to a specific timestamp (#39107)

[rduivenvoorde]

See: https://github.com/qgis/QGIS/blob/master/src/core/qgstemporalnavigationobject.h#L132
"Calling this (setFrameDuration) will reset the currentFrameNumber() to the first frame."
and
https://github.com/qgis/QGIS/blob/master/src/core/qgstemporalnavigationobject.cpp#L196

So not a 'bug' but more like a feature request :-) ?

So you would want QGIS to calculate the new frames, and then choose the nearest frame (to your old position)?
That sounds reasonable. As a quick hack you could change the start Range input to the desired value (though I'm aware that if you are fiddling with the inputs, that you are not aware what current frame was.....

[anitagraser]

Nice, so it's a well documented bug :-)

So you would want QGIS to calculate the new frames, and then choose the nearest frame (to your old position)? That sounds reasonable.

TimeManager behavior was to keep the map start time stable and adjust the map end time according to the new settings.

[rduivenvoorde]

@anitagraser I think I can tackle this. One important difference (I think) between the TimeManager (TM) and current Temporal Controller (TC), is that TimeManager's state was 'loose', that is in the time-slider, you could 'set' the slider on random positions. While in TC the position is determined by the start of current timeframe.
So for example given an (hourly) dataset of 24 hours, starting at 01:00.
With a timestep of 1 hour you can step 1 hour (in the range of frames: 01:00-02:00, 02:00-03:00 etc etc)
If you change the timestep to 2 hours the steps change (in the range of frames: 1:00-3:00,3.00-5:00 etc etc)
So if the slider is on position 2:00 (which is possible when taking 1 hour steps), IF you go to 2 hour steps, the position is currently NOT available (as only 1,3,5 etc... are valid starttimes of the 2 hour frames). So in my current setup you then go back to 1:00.
Off course if the 'tick' in the slider fits exactly the slider also stays exactly on that point.
What I want to say: the model of TM is a little different from TC so there is no exact copy of functionality possible.
Let me clean up my prototype, do a Pull Request, so you can test.

[anitagraser]

Thanks @rduivenvoorde!
Just thinking while typing here: if TM behavior is what users expect (and I'm not sure about that, we'd have to run a test), it might be possible to imitate this behavior in TC by adjusting the start of the TC time frame in a way that keeps the current slider position a valid frame start time.

[nyalldawson]

I'm personally +1 to @rduivenvoorde's approach. (I think if a user is wanting to view an exact time frame and then adjust the duration, they should be using the time filter mode in the widget rather than the animation mode.)

[anitagraser]

I'm certainly biased and happy to give this approach a try 🙂

The usual use case for me is to browse through a dataset, and at one point realizing that I'd like to see a bit longer time frame. This is much more common for me than knowing an exact time from the beginning.

[nyalldawson]

Another option we could do is have little "lock" icons next to different settings in the widget. So if "frame start time" is locked then the overall animation start would be adjusted. If the animation start time is locked, then the frame time is adjusted...

[rduivenvoorde]

In TimeManager in my own branch, I had 2 'modes', because that is (what I think) we are talking about:

• TimeManager default approach: a 'sliding timeframe' (so no 'fixed tickes' I called the other alternative mode)
• Temporal Controller's default approach: 'fixed ticks': if starting in an uneven hour, you can (when stepping in 2 hours steps) never start a timeframe which starts with an even hour (just found my unmerged PR: WIP: working ticks in slider, Working tickbox for 'discreteTimeStep' anitagraser/TimeManager#195)

BOTH 'modes' have their merits/use-cases.

I was bitten bij TimeManager's approach when using WMS-T servers, these often require these 'fixed ticks' when you browse the data (e.g 'yearly rainfall'-data has fixed timeframes (eg. always starting at the first of januari), so you are not suppossed to ask for images of rainfall from june till june... (that is probably the reason we have this model, it started of as WMS-T implementation @Samweli ?).

My gutfeeling is that the 'fixed tick'/current TC mode is more restricted but a little 'easier' to implement/handle corner cases.

But as shown by Anita: there are certainly use cases (especially when you have 'free vector' data to filter (so no fixed 'buckets').
I think both are possible to do, it is just for the user not so clear which mode to choose from... (as some data can only handle one, other data can handle both modes).

[nyalldawson]

@rduivenvoorde

What you describe is exactly the intention of the split between the time filter "fixed range" mode and the "animation" mode, and I completely agree that both use cases are important.

What's missing is that the fixed range mode doesn't give such as nice UI for setting the visible range. What we really need here is a "double edged" slider, where both the start and end time can be freely dragged to set the start and end of the visible time slice accordingly.

This would then match the behavior seen in google earth and arcmap:

The only reason this hasn't been done yet is the Qt doesn't have any native widgets for a "double end slider", and we couldn't find any nice 3rd party widgets which were suitable drop-ins...

[nyalldawson]

I was bitten bij TimeManager's approach when using WMS-T servers, these often require these 'fixed ticks' when you browse the data (e.g 'yearly rainfall'-data has fixed timeframes (eg. always starting at the first of januari), so you are not suppossed to ask for images of rainfall from june till june... (that is probably the reason we have this model, it started of as WMS-T implementation @Samweli ?).

And this situation should already be nicely handled, because the WMS-T layers have support for picking the most appropriate available image, via this option:

[rduivenvoorde]

I was bitten bij TimeManager's approach when using WMS-T servers, these often require these 'fixed ticks' when you browse the data (e.g 'yearly rainfall'-data has fixed timeframes (eg. always starting at the first of januari), so you are not suppossed to ask for images of rainfall from june till june... (that is probably the reason we have this model, it started of as WMS-T implementation @Samweli ?).

And this situation should already be nicely handled, because the WMS-T layers have support for picking the most appropriate available image, via this option:

Ouch, that is nicely hidden in the Source tab of the layer. Honestly never seen it...
@Samweli @nyalldawson Would it not be better if this would be a (dynamic showing) part of the Temporal tabin the layer props?

Is 'Time slice mode' clear what it means to others?

Using http://geoservices.knmi.nl/cgi-bin/RADNL_OPER_R___25PCPRR_L3.cgi? here:

To me the word 'Range' in the 'Time slice mode' drop down is confusing, I think. It is actually the 'Time Frame' we are talking about isn't it? It is if you use only the start of current frame (&TIME=2020-11-14T00:00:00Z) or only the end (&TIME=2020-11-15T00:00:00Z), of a real 'range' beging from start to end (&TIME=2020-11-14T00:00:00Z/2020-11-15T00:00:00Z).
Another observation: the NOTE is disabled, although it is still valid I think:

[anitagraser]

Ouch, that is nicely hidden in the Source tab of the layer. Honestly never seen it...
@Samweli @nyalldawson Would it not be better if this would be a (dynamic showing) part of the Temporal tabin the layer props?

Exactly! That's why I opened #36552

[rduivenvoorde]

What you describe is exactly the intention of the split between the time filter "fixed range" mode and the "animation" mode, and I completely agree that both use cases are important.

@nyalldawson this 'fixed frame mode' has never been clear to me. To me it always looked as if I wanted to only see a one time 'slice' of my data?

While in the TimeManager (and the usecase you describe with the 'double slider') is that you can still 'play/animate' (after you set an arbitrary start and an end frame (and thus size of timeframe).

[Samweli]

Hi @rduivenvoorde, @anitagraser @nyalldawson

Ouch, that is nicely hidden in the Source tab of the layer. Honestly never seen it...
@Samweli @nyalldawson Would it not be better if this would be a (dynamic showing) part of the Temporal tabin the layer props?

The WMS-T settings in source tab can be used with or without the Temporal Controller, moving these settings into the Temporal tab might confuse users who just want to fetch a WMS-T resource and do nothing about the Temporal Controller or the layer's temporal properties.

To me the word 'Range' in the 'Time slice mode' drop down is confusing, I think. It is actually the 'Time Frame' we are talking about isn't it?

Yes, in the context of using these settings with the Temporal Controller, might need to find words that fit both use cases.