Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing tiles returned as 256x256 transparent tiles #154

Closed
cns-solutions-admin opened this issue Aug 29, 2022 · 11 comments · Fixed by #177
Closed

Missing tiles returned as 256x256 transparent tiles #154

cns-solutions-admin opened this issue Aug 29, 2022 · 11 comments · Fixed by #177

Comments

@cns-solutions-admin
Copy link

cns-solutions-admin commented Aug 29, 2022

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.

@cns-solutions-admin
Copy link
Author

Just found out that tileserver-gl and others intentionally return 204 on tile-not-found: maptiler/tileserver-gl#46

@brendan-ward
Copy link
Collaborator

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.

@brendan-ward
Copy link
Collaborator

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.

@brendan-ward
Copy link
Collaborator

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.

@cns-solutions-admin
Copy link
Author

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?

@brendan-ward
Copy link
Collaborator

@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.

@cns-solutions-admin
Copy link
Author

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.

@alienatorZ
Copy link

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.

@brendan-ward
Copy link
Collaborator

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.

@alienatorZ
Copy link

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?

@brendan-ward
Copy link
Collaborator

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants