datasets with variable maxzoom

[prusswan]

Related to syncpoint/openvtpk#22, apparently vtpk can contain a mixture of maxzoom (15 and 16). So for the affected areas, the client needs to be able to retain data from the previous zoom, and not blank out just because no data exists at maxzoom.

#48 seems to suggest Leaflet is not able to support such data, but MapLibre does, is this understanding correct?

[bdon]

(Moving to discussions)

the fixed maxzoom is a limitation of how extents are defined in Leaflet and MapLibre GL JS. There is a proposal in MapLibre GL JS that generated a lot of discussion for pyramids that are deeper in some areas than others, but I'm having trouble finding it right now.

In any case PMTiles can store sparse pyramids, but how that variable overzoom is communicated to the client isn't well defined in any of those open source rendering implementations. If you can come up with such a definition that can be stored in the PMTiles metadata JSON, as it's not part of any existing spec like TileJSON.

[prusswan]

if you load z15 and then scroll to z16, and the maxzoom is set to 16 but the tiles are missing / 404 responses, the z15 tile should remain over zoomed.

This might not be working properly (see below), even the tile inspector will discard z15 data when it is supposedly replaced by non-existent z16 data:

I have added some converted tiles (in both mbtiles/pmtiles) in case others are able to figure something out:

OSM_firenze_vtpk.zip

[prusswan]

Surprisingly, only ol-pmtiles is able to work with such tiles properly (for overzooming). I'm not too familiar with maplibre's pmtiles protocol, but this seems to indicate a bug with tile handling.

[bdon]

Could It be that a Z15 tile is evicted once any of the 4 child Z16 tiles is successfully loaded, to avoid showing duplicated, overlapping tiles?

[prusswan]

Makes sense. Would it help to have a parameter to delay this eviction? For raster tiles, overlapping tiles is not an issue (since only whatever that is right on top would be visible), but for vector tiles, the parent tile could be subdivided and used to prefill the child tiles (even if they do not eventually load).

[bdon]

It might be a useful feature to propose in MapLibre but it's out of scope for the PMTiles library.

[etiennejourdier]

Hi,
I'm reopening the discussion because I'm having problems displaying sparse pmtiles in maplibre : as noticed above by @prusswan maplibre is not overzooming in for example z13 when z14 is not available.
Based on this discussion on github/maplibre-gl-js, it seems to me that maplibre will overzoom if the requested tile returns a 404 error, whereas the pmtiles.js protocol response is empty without error when a tile is not available. Did I understand well ? How can I modify the pmtiles.pj protocol to test this hypothesis: returns a 404 error instead of a blank tile ?
Thanks !
E.

[etiennejourdier]

I don't know if this is a useful information, but during my test, I observed the same behaviour (overzoom) as soon as I throw an error, whatever the error code 4xx (set with error.status = 4xx). Even values 5xx or 2xx gave the same behaviour, but maybe it is because I throw an Error ?

[bdon]

Yes, I think Maplibre is conservative and keeps the loaded tile if it encounters an error.

So what I see is that in some cases developers are depending on the maplibre error behavior for overzooming, and they cannot reproduce the functionality using PMTiles. I would prefer in the long term MapLibre has a real solution like defining tile pyramids, but as a temporary solution we can add a protocol parameter alongside metadata called errorIfMissingTile, that would let you opt into the maplibre behavior, what do you think?

[HarelM]

The following was suggested to solve this in maplibre from a specification point of view:

• Design Proposal: Allow overzoom for sparse pyramids tiles maplibre/maplibre-style-spec#938

Having said that, I think it would be much faster to implement something here as a temporary workaround until the above enhancement lands in Maplibre.
errorIfMissingTile sounds like a good name for this.

[bdon]

The error messages that would appear in the console if errorIfMissingTIle is still a problem but IMO an acceptable tradeoff because the same error messages happens with MapLibre and 404s. I think it is cleaner to patch this problem here instead of making a change to the maplibre specification in the above link.

@etiennejourdier it is worth looking at the maplibre source code to see if there is any way to invoke this situation without the error message.

[etiennejourdier]

it is worth looking at the maplibre source code to see if there is any way to invoke this situation without the error message.

Unfortunately I'm an amateur developer, so I clearly don't have the skills to delve into maplibre's source code...

[HarelM]

There is a proposal in MapLibre GL JS that generated a lot of discussion for pyramids that are deeper in some areas than others, but I'm having trouble finding it right now.

Here it is for future reference:

• Design Proposal: Expanding tileSources bounds maplibre/maplibre-style-spec#60