Wrong layers order, depends on zoom level (starting in v5.0.0)

[igal1c0de4n]

maplibre-gl-js version: 5.0.0
maplibre-gl-js version where issue doesn't exist: 4.7.1

browser:
Chrome Version 131.0.6778.205 (Official Build) (arm64) on macos
Safari Version 18.2 (20620.1.16.11.8)
Firefox 131.0.3 (aarch64) + 133.0.3 (aarch64)

Steps to Trigger Behavior

1. Open this Mapme published map:
   https://viewer-qa1.test.mapme.com/0684b9d9-9449-42f7-bb7d-f230b631f282
2. There are two nearby locations: Chicago-1 and Chicago-2.
   Each location is associated with a different zoom level: 15 and 17 accordingly.
3. Click on Chicago-1, the map shows:
   
4. Click on Chicago-2, the map shows:
   
5. There are two relevant layers:

• Army green "grass" layer
• Gray "sidewalk" layer

Expected Behavior

• The "sidewalk" layer should be above the "grass" layer at all times (as visualized in the maptiler studio app when editing the style).
• The layers order should remain unchanged when zooming in/out.

Actual Behavior

• Parts of the "grass" layer shows above the "sidewalk" layer for zoom 15 and below.
• The "grass" layer shows below the "sidewalk" layer for zoom 17 and above.
  In more detail, the upper-left part of the screenshot (item 4 above) shows the unexpected behavior persists even when the map zoom is above 17.
  Meaning, zooming in in some cases helps, however doesn't always "fix" the layers order for some tiles.

Link to Demonstration

https://viewer-qa1.test.mapme.com/0684b9d9-9449-42f7-bb7d-f230b631f282

Note:
This is a temporary url to mapme's testing environment.
It will show the issue for the next days following the creation of this ticket.
If access is required at a later point, pls sync with me at [email protected] (also Slack handle)

Style:

https://api.maptiler.com/maps/0bdca22c-7a7c-4d7f-8eb6-3e7a21469305/style.json?key=iH0qvXB6CpZUVu9oKlXL
Developers may use it for debug. This style will be terminated when no longer needed.

Console error

(possibly related)

[HarelM]

Is it possible to create a minimal reproduction in terms of the minimal amount of layers?
I would also try and narrow down which pre-release might have caused this and look for a potential offending PR.
Please also check if this is not related somehow to the geometry-type breaking change that was introduced in version 5.

[igal1c0de4n]

1. Minimal reproduction case, to clarify:
   Do you mean to reduce layers which are "baked-in" the maptiler style, or layers added programmatically by the app?
   The issue persists if all programmatically-added layers (e.g. map markers) are removed.
   For example: https://viewer-qa1.test.mapme.com/73fda4cf-ba4e-4706-adc8-89617550301c
2. 5.0.0-pre.9 first reproduces this issue. With 5.0.0-pre.8 I wasn't able to.
3. We don't use geometry-type

[HarelM]

I mean a reproduction that has like 4-5 layers without the maptiler style at all if possible.
A jsbin/codepen/stackblitz would be better to avoid dead links in the future if anyone would return to this issue.
I've looked at the changelog and I can only think about 2 PR that might have caused this if you are not using geometry-type:
https://github.com/maplibre/maplibre-gl-js/blob/main/CHANGELOG.md#500-pre9

• fix: Convert WebGL1 shaders to WebGL2 #5166
• Fix render world copies regression #5101

Feel free to try and see if you can narrow down to the PR that created this issue, maybe we could better understand what might have caused this.

[igal1c0de4n]

jsbin which reproduces the issue with the originally provided style:
https://jsbin.com/coxuneb/edit?html,output
(to reproduce simply open link and zoom in)

I wasn't able to reproduce it with other off-the-shelf styles e.g. example: https://jsbin.com/huyarum/edit?html,output
There seems to be something specific with the original style (still, it worked well in previous versions, so it should be legit)

[igal1c0de4n]

Re narrow-down to the PR which caused it:
I link to the unpkg.com maplibregl and not quite set up to build it locally.
If you provide a url for a test build which reverts any/both of those commits, I can retest.
Although, with the jsbin I provided it's probably faster to test it locally (assuming one has a dev env already set up)

[HarelM]

I see geometry-type in the style.json you linked.
I would assume this is what's causing this issue:

[igal1c0de4n]

I apologize for the confusion, wasn't aware the style may also contain ["geometry-type"].

As I understand, mapTiler styles may include geometry-type instances where now $type should now be used instead.
Are such styles expected to behave incorrectly across the board with setStyle(/* style url */) api?

Also, what's the best approach to get this style to behave correctly?

The only solution I can think of is to change my app to:

1. http GET the style from url
2. Parse it into a js object
3. Loop over the style object and replace ["geometry-type"] with "$type"
4. Apply the result via the maplibregl setStyle(/* js object */) api

Is my understanding correct?

[HarelM]

I'm not sure, where is the style coming from? Can't you simply edit the style?
A possible option is to fetch the style and replace, but then you might "loose" cases where the author of the style wanted to use geometry-type for multi-type geometries as this is what this change was all about...

[igal1c0de4n]

1. The style is published by mapTiler on https://cloud.maptiler.com/ and they provide the style url as in screenshot:

2. Are you saying that I can't be sure the below pattern means the replacement is applicable 100% of the cases?

[HarelM]

Yes, if the someone would like to color only multipolygons the above replacement won't work.