WMS-T freezing up QGIS for long time when switching to TimeStep of seconds

[rduivenvoorde]

Really don't know what is going on, but if I load a WMS-T layer in QGIS, for example this rain radar service:

http://geoservices.knmi.nl/cgi-bin/RADNL_OPER_R___25PCPRR_L3.cgi

All is fine: starting the temporal controller, and setting the timestep to one hour or 1 day (it is actually a 5 minute service), all is fine: you can see (network logger) QGIS requesting the images etc etc.

BUT: if you set the TimeStepUnit drop down to something like seconds (or milliseconds) QGIS freezes (with me as in: the dropdown turns dark grey, the fan of my laptop starts spinning etcetc) NO images are being requested, and then after about 70 seconds the dropdown turns light grey again, NO images is being requested. In the image below I changed the dropdown from minutes to seconds

Going back to minutes is ok again.

[rduivenvoorde]

Reproducable in master and 3.16 on Windows and Linux

[nyalldawson]

There's two things happening here:

1. The freeze: caused by iterating over seconds from 2012-2020, within QgsTemporalNavigationObject::findBestFrameNumberForFrameStart -- there's a LOT of calculations happening here! We're probably best off optimising that function by doing some kind of initial guess at the frame based on the overall time range, and then refining from there (instead of starting at the start and iterating through)
2. The service returns an error for some date time ranges - eg https://geoservices.knmi.nl/cgi-bin/RADNL_OPER_R___25PCPRR_L3.cgi?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&BBOX=48.89529499999999729,0,55.97359199999999646,10.85644399999999976&CRS=EPSG:4326&WIDTH=1422&HEIGHT=928&LAYERS=RADNL_OPER_R___25PCPRR_L3_COLOR&STYLES=&TIME=2018-02-22T21:55:28Z&FORMAT=image/png&DPI=96&MAP_RESOLUTION=96&FORMAT_OPTIONS=dpi:96&TRANSPARENT=TRUE . If you change the Time Slice Mode to "closest match to start of range" then things work OK.

[rduivenvoorde]

Thanks @nyalldawson, for diving into this.

For point 1. calculation optimalisation would be nice, but in the case of this service, there IS data from 2012 till 2020 per 5 minutes, so the data extent IS huge. So only thing I can come up with is: IF service has a PM5 (=5Minutes) TimeExtent in it's capabilities, then (maybe?) disable the seconds/milliseconds part in the dropdown? (not preferable though)

One optimalisation I see: if setting the Range via the input, do NOT start calculating if the time is not valid (as in: if you start to type '28' do not start when I only typed '2')

For point 2. I started off to sent an issue-report to the service, but then thought: no they are just plain right:
Defined as a PM5 service:
TIME=2018-02-22T21:55:28Z IS wrong
and
TIME=2018-02-22T21:55:00Z IS right
(although they could be a little more forgiving)...

BUT.. they sent a HTTP 200 WITH an exception report... I think that is OK (cannot find anything about sending a non 200 in case of a OGC exception).
BUT: I think QGIS should show 'something' upon a failing request:

• you cannot easily see it in the Debugging Tools window (as the status is 200, so the line is just black and OK)
• it IS shown in the WMS tab of the messages, but that does NOT pop up or so (only the little 3 dots in the icon) show there is something wrong:
  

What about:

1. color OGC lines red (just like when you receive a non 200) in the Network Logger when there is an exception (not sure if that is easy to catch though...)
2. maybe color the little message bubble red instead of only adding the little 3 dots? Or even let it pop up? Or show something in the status bar?

I tried to lookup info about 'forgiveness' in the TIME param, but could NOT find something in the WMS specs,
and only partly related in the mapserver and geoserver docs:
https://www.mapserver.org/ogc/wms_time.html#limiting-the-time-formats-to-use
and
https://docs.geoserver.org/latest/en/user/services/wms/time.html#reduced-accuracy-times

[rduivenvoorde]

Found out the this was actually my own faulty code... So tried to fix it :-)

[Samweli]

@rduivenvoorde you can also look at #35749 it contains an approach that avoids looping over list of datetimes to search for a desired datetime, given the datetimes interval is constant and known.