Mapbox-gl-js: Is there a z-index like property?

[gabrielmoncea]

mapbox-gl-js version: 0.45.0

Question

Is there a z-index like property for layers?

I had one big geojson vector layer, which I had to split based on its gender property because it was to big and the zoom extent from which it was visible wasn't enough. But because it has many points, depending which layer comes lasts, it overlaps on the other one. In some case this is needed, but in my particular case, I need them to be at the same z-index (let's use this css property for now).

Is there a property for layers that does this, because I couldn't find it in the docs? If not, have you think of implementing this feature? I am pretty sure mapbox users would be very happy to have this feature.

[mourner]

Currently there's no such property, and the draw order fully depends on the layer order. We're looking into introducing a z-index-like property as a part of #4225, but that will take a while to get implemented.

[andrewharvey]

possibly a duplicate of #1349

[areichman]

@mourner Using the same vector tile as the source, I see a reversed rendering order when using a circle layer versus a symbol layer. Does that make sense or would you expect them to be the same?

In my case, I have time sequential data and there may be two markers with different timestamps at the same location. The circle layer shows the newest marker on top while the symbol layer shows the oldest on top. When clicking on each layer, queryRenderedFeatures returns them in reverse order of each other too.

Edit: I realize now the original question was in regards to layer order., whereas my comment is about feature order within a layer.

[mourner]

@areichman not sure — maybe @ChrisLoer can chime in on this.

[ChrisLoer]

Hi @areichman, I believe the difference you're seeing between circle layers and symbol layers is because we sort the rendering order of symbol features within a layer based on their y-position: https://github.com/mapbox/mapbox-gl-js/issues/470. The idea there is that when you have a lot of overlapping icons, consistently sorting them based on y-position makes them look less "jumbled".

4361 (#1349 mentioned by @andrewharvey is another duplicate) proposes adding explicit sort order control, which I think would be the best way to address this. But for some purposes it might make sense to just turn off the y-position sorting for symbol layers (when you're providing the data for the symbol layer and you control the order of the data to match your desired render order).

[cs09g]

@ChrisLoer

when you're providing the data for the symbol layer and you control the order of the data to match your desired render order

How can I add data for order and how to use those for render order? Okay, first, I set order value in fields in tilejson, then what should I do or How the library detects it? is there a reserved keyword for render order?

[ryanhamley]

@cs09g Setting the symbol-z-order style spec property to source will prevent sorting on symbol layers, which means they will be rendered in the same order as your source data. It's not possible at this time to sort other layer types in this way.

[cs09g]

@ryanhamley There's no order of data. sources is the same. it is objects. how does it recognize its features rendering order? so, how it can be sorted, by what value of layer or each feature?
I have many features in a layer and want to give priority(z-index) for each feature in case they overlaps.

[ryanhamley]

If your source is a FeatureCollection with an array of features, then setting symbol-z-order: 'source' on the style will render the features in the order they appear in the array, instead of sorting them by their y position on the viewport.

[kukiel]

Hi guys,
is there any plan to introduce some ordering mechanism (like z-index)? I do have many layers of different types and proper order plays key role. I must say I am having hard time to keep the right order whenever introducing new layer or when there is a need to reorder layers.

Maybe there is some new API I am not aware of or some tips on how to manage order. Will appreciate an update on this topic.

[areichman]

@kukiel I usually create some dummy GeoJSON layers and then reference them using the beforeId attribute when adding layers.

e.g.

map.addSource('empty', {
  type: 'geojson',
  data: { type: 'FeatureCollection', features: [] }
});

const zIndex2 = map.addLayer({
  id: 'z-index-2',
  type: 'symbol',
  source: 'empty'
});

const zIndex1 = map.addLayer({
  id: 'z-index-1',
  type: 'symbol',
  source: 'empty'
}, 'z-index-2'); // place this layer below zIndex2

const polygons = map.addLayer({
  id: 'my-polygons',
  type: 'symbol',
  source: myPolygons
}, 'z-index-1'); // place the polygons on the bottom

const points = map.addLayer({
  id: 'my-real-points',
  type: 'symbol',
  source: myPoints
}, 'z-index-2'); // place the points above the polygons

Edit: I do this when I have lots of different layers that may be toggled on/off, so the dummy layers give me something I can always refer to. In the example above, if my-polygons and my-points are always on the map, you can use the beforeId to place the polygons directly underneath the points without the extra overhead of the zIndex* layers.

[kukiel]

@areichman thanks for sharing, I was actually thinking of something similar but was also hoping maybe there is/will be something built-in.