-
-
Notifications
You must be signed in to change notification settings - Fork 70
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
Design Proposal: Allow overzoom for sparse pyramids tiles #938
Comments
I recognize this as an issue of variable effective maxzoom in a single tileset, which is something not accounted for by the vector tile specs (if a tileset declares maxzoom=n it should have the tiles at that level - whether the tile server respond with an error or blank tile should not matter). While I don't expect libraries to handle this, if a solution can be found for maplibre JS, then it can possibly be applied for other client libraries as well. In cases where you are using/combining external tile sources that you cannot modify, client side fixes would be necessary anyway. |
I finally got around to test all combinations of maplibre-native/maplibre-gl-js, raster/vector tiles and 204/404 http result for this. As suspected, maplibre-native has overzoomEmptyTiles: true per default for raster sources both for 204 and 404 results, but not for vector sources. maplibre-gl-js on the other hand only has overzoomEmptyTiles: true for raster sources and 404 results. First step should be to get a definitive conclusion what the correct default behavior is and fix the discrepancy between maplibre-native and maplibre-gl-js. Side node, while I understand overzoomEmptyTiles from the context, it reads strange as it is not the empty tile itself that gets overzoomed. |
Can you put it in a table? I don't want to interpret the sentence wrong... |
sure For vector sources:
For raster sources:
empty: rendering an empty tile, i.e. a vector tile without any geometry or a transparent image |
actually I'm not sure I really tested the vector 404 case, will have to redo that. it seems strange to me that there is no fallback in that case... |
I agree, in my case (vector tiles, maplibre-GL-JS, 404 error) I observed overscale behavior. |
Just checked the 404 vector tiles case again with maplibre-gl-js 4.7.1 and maplibre-native glfw-app on mac. I don't see any overscaling at all. So the tables seem to be correct as written. |
The behaviour you've observed seems really strange to me, I've deployed a sparse pyramid pmtiles on my website for 1 month, with pmtiles protocol throwing 404 errors (using new option errorOnMissingTile: true, see here), and overscaling is working perfectly well on maplibre-gl-js.
Do we use different versions of maplibre-gl-js? |
Design Proposal: Allow overzoom for sparse pyramid tiles
Motivation: help deploy light pmtiles
Vector tiles are a great opportunity for developers to host their own tile server rather than relying on a third-party service. However a full planet pmtiles in OpenMapTiles schema is more than 70 Go, which is too much for small-scale web hosting.
Hopefully most maps do not require full detail of the whole planet, but the whole planet only up to an intermediate zoom (let's say z10) to get a nice map, then full details (let's say z11-z14) only in an area of interest (a city, a state, a country, ...).
It is possible in pmtiles to store such sparse pyramid tiles, so I was expecting this behavior:
But the acual maplibre behavior is this one, with nothing visible in the rest of the world
This behavior is perfectly normal once you have noticed that the tile server logically responds an empty tile, so maplibre logically displays a transparent tile.
This behaviour is perfect when 2 sources have been declared : you want the user to see the 2nd source below when the 1st one is not available. But it is not suited for 1 sparse pmtiles source for which the "show me what's below" behavior would be to display the last available level.
MapLibre is able to overzoom the last available level when it is the maxzoom level and also when the tile server responds with a 404 error instead of an empty tile (this is the way I used to prepare the 1st image above)
Proposed Change
I propose to allow the user to choose the expected behavior when the tile server responds an empty tile:
This could be implemented in maplibre-style-spec during source definition, for example with a new parameter overzoomEmptyTile: true/false or emptyTileHandling: 'overzoom'/'transparent' that allows the user to choose the desired behavior
API Modifications
I don't know what to write in this section.
Migration Plan and Compatibility
I don't expect any compatibility issues, as the default behaviour would still be to display a transparent tile.
Rejected Alternatives
Several people (in this discussion on pmtiles repo and this one on maplibre GL JS repo) proposed to prepare 2 separate files and declare these as 2 sources. This solution is not suitable because:
This proposal will allow a single-file solution that can be easily deployed by people with few map-coding skills, on small-scale servers.
The text was updated successfully, but these errors were encountered: