How to use raster source with varying zoom levels? about maplibre-gl-js HOT 7 OPEN

I'm not sure this change was intentional, I would consider finding the last version this worked and find the relevant PR to see what might have changed and what is the description in the PR.

from maplibre-gl-js.

i believe it was this PR https://github.com/maplibre/maplibre-gl-js/pull/3428/files

if i remove the

    if (data.byteLength === 0) {
        return createImageBitmap(new ImageData(1, 1));
    }

it works like it used to, (though spams the console with this err)

DOMException: The source image could not be decoded.

from maplibre-gl-js.

This is basically intentional, if the tile server return 204 it means that it got the request for a tile, and returned an empty tile, which will be displayed in the map as empty.
If you want to get the previous behavior you'd need to configure the tile server to return 404 - which will tell maplibre that this tile doesn't exists and there's a need to overzoom.
I hope this makes sense to you.

from maplibre-gl-js.

I think the discussion in #161 (comment) and following is relevant here. So the original reasoning from mapbox was to use 204 for this use-case and not 404, because 404 triggers console errors.

from maplibre-gl-js.

that makes sense. It would be ideal if there were a toggle of some sort to have overzoom without having the 404 console spam, but it's workable how it is

from maplibre-gl-js.

Just to make sure I understand the behavior of MapLibre GL JS correctly:

Say I global satellite raster tiles up to zoom 10 and then I have higher-resolution satellite raster tiles for Switzerland up to zoom 16. If I want to mix the two together in a single raster tile source I can just say the maxzoom is 16 for the overall source and for tiles outside of Switzerland for example at z14 I could just return a 404 status code and MapLibre GL JS would overzoom the z10 tiles for me?

from maplibre-gl-js.

Thats exactly correct. The only downside of that setup is that browsers generate console messages for 404 subrequests automatically. So that setup would generate a lot of those messages and make it difficult to find 404 which are not expected and problematic among all the expected 404 messages. Thats why mapbox considered 204 as an alternative for the same behavior in the linked discussion. I never tested what their software (or maplibre-native) does in that situation though.

from maplibre-gl-js.