Can maplibre handle sparse pmtiles?

[etiennejourdier]

Hi,
I don't have the disk space on my server to host a pmtiles file with all levels for the whole planet. I was thinking of preparing a sparse pmtiles with :

• the whole planet up to zoom (let's say) 10
• my country up to zoom 14.

I'am expecting the following behaviour for levels 11 to 14:

• in my country it displays the available tiles
• elsewhere in the world, it overzooms in the level 10 tiles (the last level available)

I've done some preliminary tests on small regions and it doesn't seem to work:

• I have to indicate in the pmtiles metadata that the levels go from 0 to 14 otherwise it won't look for tiles at levels 11-14 when zooming in my country
• and so, elsewhere in the world, it looks for tiles from levels 11 to 14, which don't exist, so it doesn't display anything anymore, instead of overzooming in the last available level (level 10).

Is it possible to handle sparse pmtiles with overzooming in the last available level ? Is it a question for maplibre developers or pmtiles developers ?
Thanks !
Etienne

[HarelM]

I believe the solution would involve 2 pmtiles behind a tile server and routing though nginx rules. I haven't tried that, but I think you should be able to make it work...

[etiennejourdier]

OK, I patched the pmtiles protocol to throw a 404 error instead of an empty array, and it works just as expected : z12 tiles are overzoomed by maplibre when z13 or z14 tiles return errors. You can see more details in this discussion.
Now, how can we make this behaviour accessible to other people who would like to use sparse pmtiles?
Can I ask maplibre developers to include an additional parameter for overzooming when the tile is empty, not only when there is a 404 response? or would it not be compatible with other maplibre functions?

[HarelM]

Empty content in http is marked with 204 status code.
I'm not sure what was the last decision around this, see here:
#3428

It would be interesting to see if this is something you can configure for pmtiles library, as the return of empty tile is "hard coded" choice and it might make sense to allow defining a different behavior in certain cases.

Generally speaking, and empty response is a valid one, and I'm not sure we want to start hacking the code in order to change the behavior of empty tiles...

[etiennejourdier]

I agree that an empty response is a valid one, and I'd rather keep it that way than throw in a lot of errors. However, from a graphic designer's perspective, a transparent layer means "show me what's below". When the user has several sources, it is logical that below refers to another source. But when the user has only 1 source, it is logical that below refers to the previous level in that source. So to my point of view, when the user defines a source, he should be able to choose maplibre behaviour when handling empty tiles : either display nothing, or overzoom the previous level in that source. We could imagine for example an empty-tile-handling parameter in the source definition.
Obviously, I'm saying this without having any idea of the complexity of all the cases that maplibre must be able to manage.

[HarelM]

You are welcome to open a design proposal in the maplibre-style-spec repo and proceed with the relevant implementation if this is something that you would like to push forward.

[etiennejourdier]

OK I 'll do that !

[acalcutt]

I have not tested this with vector tiles, but I have been looking at something similar with terrain raster-dem files. I talked with wipfli initially and he had given me some ideas for layering raster tiles with addprotocol that replaced specific tiles. That worked, but it wasn't very flexible since you had to specify every tile you wanted to replace at every zoom level.

I took that example and asked google AI to make a function that would check if a higher zoom tile was withing a lower zoon tile, and it gave me the function I used in this example. I used that function to show a different source when the tile is within the tiles (5/16/11, 5/17/11, 5/16/12, 5/17/12)
https://stackblitz.com/edit/web-platform-j8cf5x?file=index.html

In my example the main source goes to zoom 12, but the source in the (5/16/11, 5/17/11, 5/16/12, 5/17/12) areas go up to zoom 14. For the most part it seems with terrain that it does try to load lower zoom tiles if the higher zoom tiles don't exist. However even though the terrain works, I think I have also run into some issues caused tile zoom level being different from the max zoom on the source (specifically 'merged_terrain_source' in my example). For example, When I use it with a style that includes buildings and am looking in an area that only goes to zoom 12 instead of the source max zoom of 14, it seems to cause the building to float (which does not happen in the areas that actually go to zoom 14)
https://stackblitz.com/edit/web-platform-mkbj4hau?file=index.html

this does not seem to happen in areas that actually go to zoom 14 (for example)

It also goes away if i set the 'merged_terrain_source' to max zoom of 12, but then it wouldn't load the higher zoom tiles where they are available.

[acalcutt]

in testing I looked at the developer tools network tab and can see it loads lower zoom tiles. like this for example, you can see it failed to load higher zoom images (which were at zoom 14 and 13) and then successfully loads a zoom 12 tile

I would imagine you would see something similar with pbf files if it was working.