Control.Layers dont preserve layers order

[mrit64]

• Leaflet version I'm using: 1.0.2
• Browser (with version) I'm using: Chrome & FF
• OS/Platform (with version) I'm using: Windows 10

What behaviour I'm expecting and which behaviour I'm seeing

Documentation say about Control.Layers's autoZIndex option : If true, the control will assign zIndexes in increasing order to all of its layers so that the order is preserved when switching them on/off.

It's not working as expected : the order is NOT preserved when switching them on/off.

Minimal example reproducing the issue

https://jsfiddle.net/mrit64/z1v8v6nv/

[IvanSanchez]

The problem here is that the autoZIndex option, as well as the setZIndex() method only affect GridLayers, and only those within the same map pane.

Read (if you haven't done so yet) the map panes tutorial for a workaround.

This (paired with the functionality that map panes provide) can make a case for making setZIndex obsolete. Right now I'm thinking about amending just the documentation to make it clear that autoZIndex only works for the order of GridLayers/TileLayers.

[mrit64]

OK, autoZIndex is not made for overlay layers. Thanks for the precision.
Clarifying the documentation could help, I agree.
I am using Panes. They work well in SVG layers, but I have difficulties with Canvas layers (see #5190). Another problem with Canvas layers and panes, is that you can treat mouse events only for the top layer.

[UsgsMonkey]

I'm having difficulties with the Layers control myself. I have a set of standard FeatureLayers assigned to the 'overlayPane' and a highlight layer assigned to a custom 'HighlightPane' pane. From reading the documentation, I understand the z-level of the 'overlayPane' is set to 400, so I set the 'HighlightPane' z-index to 450. This works fine, but when users click on and off layers in the layer control, the last layer 'turned on' always ends on top and the z-level of my highlight layer is not respected (i.e. if my highlight layer is 'on' and I turn off and on one of my feature layers, when that feature layer is turned back on it renders on top of my highlight layer, despite the z-levels).

[ghybs]

Hi @UsgsMonkey,

What you describe sounds different from the exact original issue described here.

For questions on using Leaflet, please use gis.stackexchange.com or stackoverflow.

If you are really sure that this is a bug in leaflet, please open a new issue and provide code to reproduce your problem (comply with the issue template).

[answerquest]

Hi, for others just looking for ways to have one layer coming below another, I found a workaround by removing then re-rendering all my layers in the order in which I wanted them to show.

Way to retrieve the data present in a layer:
var Abackup = layerA.getLayers();

Way to remove a layer:
if(map.hasLayer(layerA)) map.removeLayer(layerA);

Way to add a layer:
if(! map.hasLayer(layerA)) map.addLayer(layerA);

[mgiraldo]

is this the expected behavior? that when i check/uncheck an overlay, regardless of the order that it had when instantiated, the last one to be checked visible will come on top?

[keul]

Default behavior apart as described by @mgiraldo, documentation for sortLayers is also confusing as says:

Whether to sort the layers. When false, layers will keep the order in which they were added to the control.

But this does not seems to follow the added order control while activation order.