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.

[prusswan]

Proposed PR here: #505

can you provide a minimal real world sample of a sparse tileset?

I attached some sample previously. It was extracted from Esri's OSM vector layer as vtpk (which led to this issue)

@etiennejourdier I think there are different situations, so some of the alternatives may be better if you have no control over the tiles or the client code, but I understand the issue ultimately lies with the specs, and libraries are not obligated to support it (since there is no "standard" to follow). For tile generation, keeping the tilesets/layers separate is more flexible (since they can be merged anytime, for simple cases with no overlaps at least), but having more options is always good.

[bdon]

Attached is screenshot of how #505 works with the sample file - it shows an error in the console but simultaneously displays z14 and z15 tiles.

[bdon]

@etiennejourdier @prusswan I published pmtiles v4.1.0 with an errorOnMissingTile option:

let protocol = new pmtiles.Protocol({metadata: true, errorOnMissingTile: true});

[etiennejourdier]

That's perfect, thanks a lot for your responsiveness !! I have just deployed this on my website (a playground directory). You can see here the behaviour at the border between the z12 zone (north) and the z14 zone (south).

[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