Open jmac125 opened 6 months ago
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.
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.
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.
I think the discussion in https://github.com/maplibre/maplibre-gl-js/pull/161#issuecomment-964224725 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.
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
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?
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.
User Story
On v3.3 i had a raster layer with data at varying zoom levels, some areas up to level 20, most up to level 10. Previously it would overzoom the tiles where i didn't have better data and get the data where i did. Now the tiles disappear when they get the 204 from tileservergl
Is there any way to use the old behavior of overzooming when dealing with a tileset with mixed zoom levels?