WMS temporal works only on certain scale

[mvaaltola]

Describe the bug
QGIS only adds the TIME parameter to WMS GetMap requests on certain scales / zoom. More specifically, the TIME-parameter is not present in GetMap requests and the latest image is always displayed, unless the map is zoomed out enough.

The cutoff for this particular case seems to be a scale 1:725300, for which requests don't contain a TIME parameter at all, and scale 1:725400 for which requests correctly contain the TIME parameter and the correct result is displayed.

How to Reproduce
Add a temporal WMS layer, open the temporal controller panel. By default the latest available image is displayed correctly. Enable animated temporal navigation. QGIS properly recognizes the temporal range of the layer as defined in the capabilities document.

Drag the frame slider in temporal controller all the way back. Nothing changes, the latest image is still displayed. Curiously, the image from the selected date does appear if zooming out the map enough. Zooming back in (to any scale) results in the latest image again.

Tried clearing cache, clean profile. Tried many different and unique scale/bbox combinations. Copying the GetMap requests QGIS makes and manually appending a TIME parameter generates the correct responses from the WMS.

Image from 2020-09-15 displayed correctly, when zoomed out to a scale of ~1:1000000

Latest image (from 2020-09-25) displayed, despite keeping the frame slider in the same position, when zooming back in to ~1:500000. Zooming further in or panning the map does not fix the issue:

QGIS and OS versions

QGIS version | 3.16.3-Hannover | QGIS code branch | Release 3.16
-- | -- | -- | --
Compiled against Qt | 5.15.2 | Running against Qt | 5.15.2
Compiled against GDAL/OGR | 3.0.4 | Running against GDAL/OGR | 3.0.4
Compiled against GEOS | 3.8.1-CAPI-1.13.3 | Running against GEOS | 3.8.1-CAPI-1.13.3
Compiled against SQLite | 3.34.1 | Running against SQLite | 3.34.1
PostgreSQL Client Version | 13.1 | SpatiaLite Version | 4.3.0a
QWT Version | 6.1.6 | QScintilla2 Version | 2.11.6
Compiled against PROJ | 6.3.2 | Running against PROJ | Rel. 6.3.2, May 1st, 2020
OS Version | Arch Linux
Active python plugins | MetaSearch; db_manager; processing

Additional context

I'm using datacube-ows to provide the WMS. It has a single layer, with the following definition in GetCapabilities.xml:

<Layer queryable="1">
<Name>cloudless_mosaic</Name>
<Title>cloudless_mosaic</Title>
<Abstract>cloudless mosaic</Abstract>
<KeywordList>
...
</KeywordList>
<EX_GeographicBoundingBox>
<westBoundLongitude>26.9998170118793</westBoundLongitude>
...
</EX_GeographicBoundingBox>
<BoundingBox CRS="EPSG:3857" minx="3005605.881273969" maxx="3117432.008633051" miny="1103172.5178095326" maxy="1215721.9344109201"/>
...
<CRS>EPSG:3857</CRS>
...
<Dimension name="time" units="ISO8601">2020-09-15T14:05:00.000Z/2020-09-25T14:00:00.000Z/PT5M</Dimension>
<Style>
...
</Style>
<Attribution>
...
</Attribution>
</Layer>

The layer has images from two dates, 2020-09-15, and 2020-09-25. I moved the slider in temporal controller all the way back to 2020-09-15 14:05. Also tried moving the slider around different times on 2020-09-15 to get it to refresh.

For testing purposes, I hardcoded the value of the Dimension tag in the capabilities document to match the format I saw in another temporal WMS capabilities document that works perfectly with QGIS. The WMS provided by datacube-ows works purely on dates and completely ignores the time part of the TIME parameter in any requests, so the somewhat incorrect time values are not causing any issues.

If the TIME parameter, such as TIME=2020-09-15T15:05:00Z, is present, the WMS returns the right image. This happens when zooming out enough in QGIS, or manually making a GetMap request in a web browser. If no TIME parameter is present, the WMS returns the latest image from 2020-09-25, as it should.

I used both the server logs and the QGIS debugging/dev tools (F12 panel) to check the GetMap requests QGIS is making to the WMS. For scale 1:725300 and closer, the TIME parameter is not added. For scale 1:725400 and further away, the TIME parameter is added.

[nyalldawson]

Can you share a public server showing this issue? It's really had to debug something like this if it requires a bunch of manual steps like installing and configuring datacube..

[rduivenvoorde]

@mvaaltola I second nyalls question: please provide an example with a public available WMS.
I often propose: http://geoservices.knmi.nl/cgi-bin/RADNL_OPER_R___25PCPRR_L3.cgi which has 8 years of rain radar data in steps of 5 minutes:

<Dimension name="time" units="ISO8601" default="2021-02-12T09:30:00Z" multipleValues="1" nearestValue="0" current="1">2012-01-01T00:00:00Z/2021-02-12T09:30:00Z/PT5M</Dimension>

I work extensively with Temporal layers/data and I have not seen the behaviour you describe.

Can you enable the Debugging/Development Tools (F12) and check what is returned on all QGIS requests?
Is it possible that the service is 'scale' or image size delimited?

As an issue in my example service above for example (== data in 5 minute steps): when you step in 1 minutes, this service only returns a valid image when you use the exact 5m boundaries... So which is not a QGIS issue, but more the user trying to request timesteps that the service is not providing (it even returns a error text)...

A lot can go wrong in this play between QGIS and a service, but a lot can go 'wrong' without really being a bug...

[mvaaltola]

@nyalldawson @rduivenvoorde I cloned the service and it's available in public for you to test here: http://qgis-wms-test.gispocoding.fi/wms?request=GetCapabilities&service=WMS&version=1.3.0. I was able to replicate the same behaviour on this service as well.

From what I understand, datacube-ows is purely date-based, i.e. "2021-01-01T09:00" and "2021-01-01T09:01:23" result in the same output. On the test service there are only images for 2020-09-15 and 2020-09-25, and I have tried manually making "invalid" requests for dates where no images are available. These result in errors. Valid GetMap for 2020-09-15 (copied from QGIS log), invalid GetMap for 2020-09-16 (same as before but different TIME). However, this is not what's happening with QGIS.

I'm not 100% sure on how to answer if the service is scale or image size delimited. Hopefully you can see this by checking the test WMS, or I can elaborate further on the details of the WMS if needed. There is a certain "scale limit", when you zoom out enough the entire image turns grey. However, I doubt it's at the root of this issue. QGIS still adds the TIME parameter to the GetMap requests on those scales as well, it's only dropped when zooming in. AFAIK, the capabilities document should contain all the information on any potential additional layer scale restrictions, etc., and I don't think there's any.

Here's a screenshot of a request from the debugging/developer tools, this one when zoomed in. Note there's no TIME param:

When I zoom out, the requests look like this. Notice there's now a TIME and the correct image from 2020-09-15 is also displayed. I didn't touch the temporal controller panel at all between these two images, only changed zoom:

[rduivenvoorde]

Ok, I can confirm. There is definitly something going wrong there.
If I load the layer in a project and save it (with say 1 hour timesteps). Then after reopening there seem to be no requests fired if I step with the Temporal Controller.
Then moving the timestep size to minutes, A LOT of requests seem to be fired, of which a lot of them indeed without TIME parameter...
@mvaaltola note that the capabilities state:

<Dimension name="time" units="ISO8601">
2020-09-15T14:05:00.000Z/2020-09-25T14:00:00.000Z/PT5M
</Dimension>

So apparently (according to this) 5Min intervals??

Also note that it is NOT date only, in the layer properties, hidden in the 'Source'-tab there is a possibilitie to ONLY use date (without time) in the timestamps, but trying that I got:

<ServiceExceptionReport version="1.3.0" xsi:schemaLocation="http://www.opengis.net/ogc http://schemas.opengis.net/wms/1.3.0/exceptions_1_3_0.xsd">
<ServiceException code="InvalidDimensionValue" locator="Time parameter">
Time dimension value '2020-09-21' not valid for this layer
</ServiceException>
</ServiceExceptionReport>

@Samweli does this behaviour ring a bell? Else I will try to debug this later...

[mvaaltola]

@rduivenvoorde By "date-only" I simply meant that having T00:00:00, T01:23:45, so on, all produce the exact same response from datacube-ows WMS, as long as there is an image for that date. So in the case of this demo WMS, as long as the date in the TIME parameter is set to 2020-09-15 or 2020-09-25, the actual time-of-day part of the TIME parameter should not matter (even though, as you found out, it apparently is still required. Hm, maybe I'll file an issue of this for datacube-ows later).

I hardcoded the contents of the <Dimension> tag into the GetCapabilities document to match the format I saw in the Finnish Meteorological Institute's WMS service, which works well with QGIS, including temporal. The PT5M part is definitely off, but I assume it should not affect QGIS' behaviour when requesting a fixed time.

If needed, for testing purposes, I can manually set/hardcode the <Dimension> tag to something else.

[Samweli]

@Samweli does this behaviour ring a bell? Else I will try to debug this later...

Hi @rduivenvoorde @mvaaltola, I have confirmed on QGIS 3.16, The cause of this is that for the type of layer from the server provided by @mvaaltola (other service layers works fine) when zooming in, the image download request is treated as of type WMS-C instead of the normal WMS, the addition of TIME parameter is available on only WMS requests and not in WMS-C requests.
I plan to create a PR to resolve this, @rduivenvoorde did you find anything else about this? or I should go ahead a provide a fix for it.

[rduivenvoorde]

@Samweli go ahead, I gave it a shot, but failed (also see mailing list about too many requests):
https://lists.osgeo.org/pipermail/qgis-developer/2021-February/063085.html

Indeed QGIS starts as a normal WMS, but after zoom it starts, to request the surrounding 'tiles':

But I thought that was deliberate... see
https://github.com/qgis/QGIS/blob/master/src/providers/wms/qgswmsprovider.cpp#L747-L756

As said: if you think you have a clue: GO :-)

[nyalldawson]

@mvaaltola Any chance of re-starting your WMS service? I wanted to look into this one but the service is no longer responding...

[mvaaltola]

@nyalldawson a WMS for testing is available at https://cfsi-wms-demo.gispocoding.fi/wms (with an expired certificate...). I used this service to replicate the issue on QGIS 3.18.3. Please use the layer cloudless_mosaic for testing. 🙂