mbtileserver
mbtileserver copied to clipboard
consbio
Missing tiles returned as 256x256 transparent tiles
Version 0.8.2:
Currently missing (raster) tiles are always returned as 256x256 transparent tiles, even if the tile size is different, e.g. 512x512. This causes problems with some mapping software, e.g. maplibre-gl 2.3.0 terrain layers.
If a tile does not exist, the tile server should return 404 not found (or possibly 204 no content, but this might also cause problems). At least there should be a switch to enable this behavior.
Just found out that tileserver-gl and others intentionally return 204 on tile-not-found: https://github.com/maptiler/tileserver-gl/issues/46
Thanks for raising this @cns-solutions-admin ; I too had been running into errors with tile sizes for terrain tiles but had been ignoring them until now.
We can't return 404 errors; those break things for client libraries.
I'll look into using 204 instead, since that is recommended for Mapbox GL, though I think there was a reason we were using 200 with transparent tiles (maybe some client libraries didn't work well with 204s at that time).
Otherwise, maybe there is a way we can detect tile size when we detect format, and use a correctly sized transparent tile if we still need to return that with a 200 response code.
Unfortunately, it looks like both mapbox-gl-js and maplibre-gl-js (ref) both raise errors when image tiles are returned with HTTP 204 response codes. As far as I can tell, 204 works for vector tiles but not image tiles.
It looks like a cleaner fix will be to return a blank PNG of the appropriate size of a given tileset.
Pending changes in mbtiles-go to add automatic detection of tilesize to various image formats, it looks like we should be able to use that to return a blank PNG of the appropriate size. Local tests with a terrain tile shows this no longer raises an error in mapbox-gl-js.
Transparent tiles of the correct size will definitely work fine for normally displayed raster tiles (as long as the library supports an alpha channel). However, when serving terrain tiles, where each pixel corresponds to a terrain altitude, i.e. the RGBA value is interpreted as a 32bit integer height (with an offset depending on the format) and not red, green, blue and alpha, a transparent tile most probably will lead to a wrong height (instead of no height) and thus a wrong map display.
Additionally a transparent tile will still need to be drawn/combined with other layers, while a missing tile (204 or 404) might not be handled in the client library at all, thus increasing speed.
In regards to terrain tiles maplibre-gl handles 404 fine (although there are 404 not found messages in the log) and 204 semi-fine (error message about image format not being recognized, but still works).
Thus it would be nice to have at least the option to return 204/404 instead of a transparent tile (maybe a command line option like --missing-tile-result with allowed values 204/404?
@cns-solutions-admin to be clear: should the missing tiles CLI flag be only for image tiles? Seems like the recommendation for vector tiles is to always return 204.
Yes, for raster image tiles there should be an alternative to returning transparent images, returning 204 or 404. Otherwise it won't work for images that encode something other than color in the pixel data.
Has there been a fix for this? The not returning 404 for missing terrain tiles is the only thing preventing me from using this library.
We have not yet added an option to return 404 for missing image tiles, but we now return a transparent image tile of the correct size.
The problem for that approach is for terrain transparent tiles are interpreted as no-data and snapped to 0 or a no data value in mapbox/mapblibre. Are there places in the code that can be modified to return a 404 on no tile found?
@cns-solutions-admin @alienatorZ I added #177 for this; it adds a --missing-image-tile-404 option to enable returning missing image tiles as 404s. It does apply to all image tilesets on the server; there isn't an easy way to enable this only for certain services if you are serving a mix of standard display image tiles and data-encoded image tiles. The former won't break, they just result in a lot of Javascript console errors in your client.
It didn't make sense to add support for returning those as 204 as well, since that seemed like it would also break clients.
Missing vector tiles are always returned as 204.