Overzooming partially not working

[pathmapper]

mapbox-gl-js version:
v0.38.0

Steps to Trigger Behavior

1. open https://jsfiddle.net/f8kf4ps2/
2. zoom in

Expected Behavior

Lines/labels are drawn when overzooming

Actual Behavior

Some lines/labels are not drawn when overzooming / some tiles are missing (Console: GET receives 404)

The tileset layers used for the lines and labels are having a zoom range z12 - z12.

Screenshot Mapbox Studio z12.7

Screenshot Mapbox Studio z13.1

[pathmapper]

This issue is related to the custom tileset I am using for the style.

What I've done to create it:
Created several tilesets (.mbtiles) with Mapbox Studio Classic. These tilesets are having different zoom ranges and the layers are having different buffer sizes.
These separate tilesets are all working like expected with a style.

Then I've used tile-join of tippecanoe to combine these separate .mbtiles files into one.
Two layers of this single tileset (not used for the style linked with the jsfiddle above) are having a zoom extend of z9-z13.

When I replace these two layers, using a zoom range of z9-z12, overzooming works as expected.

I am unsure if this issue described above is related to:

• GL JS
• tippecanoe tile-join
• Mapbox Studio Classic
• my approach using different buffer and zoom ranges for layers in one single tileset is violation of some specs
• something else

If it's not related to GL JS, sorry for the noise.

[pathmapper]

With regard to #6803 (comment) :

I wonder if there are many cases of users relying on the current behavior of overzooming parent tiles when a 204/404 occurs.

and

#6803 (comment) :

We didn't anticipate this use case.

The motivation for merging tilesets with different maxzoom and buffer sizes in one single source was the following:

• There is data which needs to be available only for certain zoom levels. So the idea was to create tilesets only for these zoom levels to keep the size of the mbtiles files and the processing time to create them small. It seems like Mapbox not able to change the style of vector tiles at run time #6783 (comment) has a similar motivation ("It is critical in my case to not to waste the memory space by increasing the max-zoom to 21 for certain layer of features").

• For tilesets used for line layers a small tile buffer was sufficient. Tiles for symbol layers needed more buffer, to avoid the symbols being cropped at tile edges (this was before Viewport collision detection #5150).

• The single tilesets have been merged together to avoid the limit of 15 sources for styles in Mapbox Studio.

• There are no tilesets with a maxzoom > 13 because the assumption was that the performance is better using overzoomed tiles instead of loading tiles for zoom levels > 13.

[mollymerp]

@pathmapper I spent some time digging in here, and I don't know if we can fix this in GL JS without causing other maps to break. Overzooming is not working for you because some tiles at Z13 are returning 200 - OK status, so the renderer assumes it should render the tile, even if there is no data for a given style layer. I think we'd need to have per-source-layer maxzoom options in order to handle this in GL JS which I feel could add unnecessary complexity to the API.

In your process of consolidating sources, I think you need to make sure that all source layers have a shared maxzoom if you want overzooming to work correctly. I'm not sure how tile-join handles joining tilesets with different sized buffers, but I don't think the different buffer sizes are causing the behavior you're seeing.

[pathmapper]

@mollymerp thanks a lot for digging in here!

make sure that all source layers have a shared maxzoom if you want overzooming to work correctly

Yep, this is what I am doing currently.

Please feel free to close this issue.

[mollymerp]

Great! Glad you were able to find a workaround!