Drawing order Hajk group layer

[emmafrygne-vbg]

We have found a bug with the drawing order for hajk group layer. The example of how to reproduce it is from Halmstads ÖP (our isn't external yet)

To Reproduce

1. Go to https://framtidsplan2050antagande.halmstad.se/

2. Zoom in to Halmstad center and turn on the group Trafik under Mark- och vattenanvändning.

3. Look how Vägreservat is below the lines for Ny gång- och cykelväg and Trygg förbindelse som korsar barriär.
   

4. Turn off Vägreservat and turn it on again. The drawing order has changed.
   

We would like the drawing order for hajk group layers to be as it is from the start and not change.

Let me know if you want me to explain this better or if you have any questions!

[jacobwod]

Thank you for this clear description. I'll fill in with some more info.

In the first case, when the entire group is enabled, the requests looks like this:

https://framtidsplan2050antagande.halmstad.se/geoserver/op2050_a/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&FORMAT=image%2Fpng8&TRANSPARENT=true&LAYERS=op2050_a_kommunikationsreservat%2Cop2050_a_vagreservat%2Cop2050_a_forlangt_kollektivtrafikstrak%2Cop2050_a_gc_forstarkt_koppling%2Cop2050_a_ny_vag%2Cop2050_a_forbindelse_over_barriar%2Cop2050_a_resecentrum%2Cop2050_a_tagstation&INFO_FORMAT=application%2Fjson&SRS=EPSG%3A3008&TILED=false&STYLES=%2C%2C%2C%2C%2C%2C%2C&WIDTH=1298&HEIGHT=1917&BBOX=106752.79999999996%2C6278658.299999999%2C112204.39999999997%2C6286709.699999999

The second request, after toggling Vägreservat off and back on:

https://framtidsplan2050antagande.halmstad.se/geoserver/op2050_a/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&FORMAT=image%2Fpng8&TRANSPARENT=true&LAYERS=op2050_a_kommunikationsreservat%2Cop2050_a_forlangt_kollektivtrafikstrak%2Cop2050_a_gc_forstarkt_koppling%2Cop2050_a_ny_vag%2Cop2050_a_forbindelse_over_barriar%2Cop2050_a_resecentrum%2Cop2050_a_tagstation%2Cop2050_a_vagreservat&INFO_FORMAT=application%2Fjson&SRS=EPSG%3A3008&TILED=false&STYLES=%2C%2C%2C%2C%2C%2C%2C&WIDTH=1298&HEIGHT=1917&BBOX=106752.79999999996%2C6278658.299999999%2C112204.39999999997%2C6286709.699999999

The relevant part is the value of LAYERS in the request string. Notice how op2050_a_vagreservat is moved to the end in the second request:

Request 1:
LAYERS=op2050_a_kommunikationsreservat%2Cop2050_a_vagreservat%2Cop2050_a_forlangt_kollektivtrafikstrak%2Cop2050_a_gc_forstarkt_koppling%2Cop2050_a_ny_vag%2Cop2050_a_forbindelse_over_barriar%2Cop2050_a_resecentrum%2Cop2050_a_tagstation

Request 2:
LAYERS=op2050_a_kommunikationsreservat%2Cop2050_a_forlangt_kollektivtrafikstrak%2Cop2050_a_gc_forstarkt_koppling%2Cop2050_a_ny_vag%2Cop2050_a_forbindelse_over_barriar%2Cop2050_a_resecentrum%2Cop2050_a_tagstation%2Cop2050_a_vagreservat

When requesting multiple layers from a WMS service, the order of LAYERS determines zIndex in the resulting image: the leftmost layer is always at the bottom and the rightmost always on top.

This has been the case ever since we introduced group layers in Hajk and I'm sure you can reproduce with any given group layer on your setup, @emmafrygne-vbg. Nevertheless, it's a valid bug and should be fixed. Layer order from the layer's config file should be respected.

(Note to anyone who'd like to fix it: since LAYERS is an array, I guess that we simply do sublayers.push(newLayer) when we toggle. This results in newLayer being added as the last element of the array.)

[jesade-vbg]

I found it......
PR:
#1371