Style-spec slots

[davidemerritt]

I was wondering if any discussion had occurred about supporting slots https://docs.mapbox.com/style-spec/reference/slots/.

This would be a really useful tool to help us with layer ordering as we currently have to render all layers (lets say 1-10) - possibly with 0 data - because they are toggleable by the user, to maintain the correct z-index.

[HarelM]

Not that I'm aware of, generally speaking, we can't copy from mapbox so I wouldn't know how to reconcile this...

[davidemerritt]

Is there a way to create a feature request, or is this the best forum for that.

Our use case is explicitly ordered layers that the end user can toggle on/off.

With the current beforeId attribute, each layer wouldneed to understand the other layers (which is tough from a soft architecture perspective). Without using slots or an index approach we have to maintain all of the layers and use {layout: {visibility: 'none'}} to hide the ones that have been toggled off, which seems a bit of an awkward solution, but it does work.

[wipfli]

If your main use case is to toggle the visibility of multiple layers, we might also just think about introducing global variables that can be used by multiple layers...

[boeckMt]

@davidemerritt we have implemented something that might help you, but it is a bit customized for our use case...

We have some generic layer objects that serve as pointers to the layers of maplibre (based on their IDs). If you change the order of them, you can detect the change and move the layers accordingly.

• getLayerChangeOrder
• changeOrderOfLayer
• setVisibility

For Slots we have a similar concept like bottom, middle and top Filtertypes , but it is based on our generic layer objects, which only serve as containers for different LayerSpecification's, so not the layers inside the LayerSpecification

[pnorman]

Not that I'm aware of, generally speaking, we can't copy from mapbox so I wouldn't know how to reconcile this

We can't copy MapBox's implementation - but the idea of putting layers into slots isn't unique to them. We would want a developer to implement it who hasn't looked at the new Mapbox GL source code so they couldn't be tainted by it.

[j-osephlong]

I understand that we can't backport, but would it not be possible to develop something that more or less achieves the same thing without infringing on mapbox? One idea could be add a parameter to the add layer object, call it 'region', where one supplies a name for a layer stack region. The ordering of regions themselves could be first come first serve, or there could be a sort of regions definition dict in the map initialization parameters. This seems to solve the same thing, more or less. I know the implications of this would be widespread throughout the code base, but I'm just wondering if this approach would be on the same page with the maintainers of maplibre.

[wipfli]

You can achieve the functionality of slots with hidden background layers, no?

{
  "id": "my-slot",
  "type": "background",
  "layout": {"visibility": "none"}
}

[j-osephlong]

Is the idea here to use the empty layer in the beforeId parameter? That's pretty clever.

[pnorman]

I was searching for maplibre slots and it gave this somewhat amusing AI overview

In MapLibre GL, "slots" are predefined placeholder locations within a map style's layer stack that allow users to insert custom layers at specific, stable points without needing to reference individual basemap layer IDs. Defined by style authors using a "slot" layer in the style specification, they provide well-defined insertion points (like "above-polygons" or "above-poi") that ensure custom layers are positioned correctly relative to the basemap's elements, even as the basemap updates