Bug report #21049
WCS Surplus getcap, describecoverage requests
|Category:||Web Services clients/WCS|
|Affected QGIS version:||3.4.3||Regression?:||No|
|Operating System:||Easy fix?:||No|
|Pull Request or Patch supplied:||No||Resolution:|
|Crashes QGIS or corrupts data:||No||Copied to github as #:||28868|
If I add a WCS layer from here:
Every time I pan or zoom, I see that as well as making GetCoverage requests, it is also making a GetCapabilities and DescribeCoverage request. Surely these responses should be cached from when the layer was originally added?
Do not store default values in user's QgsSettings
The new behavior is to store a value in user's QSettings
(that overrides the global settings) only if the the value
has changed from the default reported by QgsSettings.
If a value was changed and it is changed back to the default
the override must be removed from the user settings.
The rationale is that global settings should be the ultimate
source of default values, unless the user override the
default with a different value.
#1 Updated by Richard Duivenvoorde over 2 years ago
Hi Jonathan, actually this was one obversion from me to, and the reason I start looking into this (and looking at a simple way to log all the requests). If i'm right the request go via a 'cachedurl'-something, so I would think that it is actually cached. But a developer could maybe tell us something more about this, or I should setup a local wcs, to check if the requests really arrive at the server.
Anyway, I totally with you that there is too much (cached or not) url traffic going on.
Another observation is that QGIS is 'sniffing' the full extent every time to find min/max values and or other stats. Which in case of a WCS in front of a really big dataset is just a not so good idea...
So maybe we can attract interesting people to this during the hackfest?