Bug report #2792
WMS Layer Order flipped in trunk (r13595) compared to QGIS 1.4
|Category:||Web Services clients/WMS|
|Affected QGIS version:||Regression?:||No|
|Operating System:||OS X||Easy fix?:||No|
|Pull Request or Patch supplied:||Resolution:||wontfix|
|Crashes QGIS or corrupts data:||Copied to github as #:||12852|
This could be a problem in my WMS server GetCaps response, but I feel nevertheless (esp until I have time to debug further) that it is crucial to note that this is a behavior change from QGIS 1.4.
My steps are:
1) Create a new WMS layer (http://tile1.dbsgeo.com) (OSM WMS just for haiti)
3) Select the '0' id (top row)
4) Add the layer
Basically, the higher number layers should come on top, but they get rendered first instead.
Basically, I am loading a WMS of OSM data with dozens of layers, and they get requested in the GetMap request
#1 Updated by Jürgen Fischer about 10 years ago
The default sort order was reversed in trunk. Now it's in order of appearance in the GetCapabilities response. The layer order for the actual GetMap requests is still in order of selection and can still be changed freely in the layer order tab.
But you couldn't add parent layers before. If you do that the children are added in sort order. So reversing the sort order before selecting '0' should do what you want.
I doubt that reversing back the default sort order would be a good thing as it'd also reverses the order of the sublevels in the layer tree, if there are more than 2 levels.
#3 Updated by springmeyer - about 10 years ago
- Resolution set to wontfix
- Status changed from Open to Closed
Okay, I've confirmed that if I change the sort order of layers in my server:
Now they show up looking right, by default with QGIS, 1.5/trunk.
And loading them up now in QGIS 1.4, they, by default, are reverse and become, in the case of OSM layers, covered by a single layer.
I now notice, with your help, that manually sorting them, by clicking "ID" will fix things. I'm not sure what do how however now, as I have folks in haiti using QGIS 1.4 that will not know that trick and my server change will bust there maps...
But, it sounds like you've fixed QGIS the right way in trunk, so thanks for noticing this. The longer the sort order was wrong the longer my server code was going to be wrong!