WMS Layer Order flipped in trunk (r13595) compared to QGIS 1.4

[springmeyer]

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) 2) Connect 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

[jef]

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.

[springmeyer]

thanks so much for these details. The server code actually was originally patched so that the GetCaps? would work properly in QGIS. So, its likely it was fixed in the wrong way. With your details I should be able to dig deeper to find the problem.

[springmeyer]

Okay, I've confirmed that if I change the sort order of layers in my server:

 http://bitbucket.org/springmeyer/ogcserver/changeset/072377ab0844

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!

Cheers,

Dane