Why MAX_MAXZOOM = 15?

[tyrauber]

I've ran through a planet wide build, and in testing, everything works great up until zoom level 16. At which the whole map goes grey. I tried tweaking the .setZoomRange(10, 24); per layer on the build profile, but that raised the error:

Max zoom must be <= 15.

In looking through the code I noticed a hard coded limit to max zoom at 15, MAX_MAXZOOM.

planetiler/planetiler-core/src/main/java/com/onthegomap/planetiler/config/PlanetilerConfig.java

Line 57 in 1375ee7

public static final int MAX_MAXZOOM = 15;

Is this a performance compromise? Or to limit build time or file size?

I made the change locally and was able to build a small region, no problem.

All the map libraries support up to a max zoom of 24. Why is Planetiler limiting the zoom to 16?

I found by setting the MAX_MAX_ZOOM to 23, I didn't need to tweak the max zoom level for the layers, they properly scaled up.

Why MAX_MAXZOOM = 15?

[bdon]

Hi Ty,

You should enable overzooming in your map: the source object in the map style should be set to 15, like here: https://github.com/protomaps/basemaps/blob/main/index.html#L45

More generally, MAX_MAXZOOM=15 is a technical limitation of Planetiler's 32-bit internal tile addressing. However, zoom 15 is sufficient for detailed mapping of typical street-level datasets when combined with overzooming, anywhere from zoom 16-20 should look fine as the renderer is re-using the zoom 15 tile.

[bdon]

You should be relying on overzooming in the client/style for zooms above 15, not data tiles existing above 15.

[YohanSciubukgian]

@bdon Thanks for the quick answer.
I understand that it's already the solution suggested on this thread.

I'm not sure to understand where the limitation is as I'm new to maps and all concepts around its tooling.
It looks like OpenStreetMap provides Tiles up to ZoomLevel=20 and where ZoomLevel=17 looks to be the right level for managing addresses as per their OpenStreetMap Wiki Zoom_levels

AFAIU, OuvertureMaps is based on OpenStreetMaps and they are adding even more details based on big tech providers to have better global coverage of the map, also adding 3D buildings and more. Don't they also plan to add more zoomLevel details on existing OpenStreetMap data if there is any ZoomLevel 15 limitation today?

I'm looking for building a map which could provide such level of details without sacrificing user XP with overzooming feature (I understand that overzooming will not add more details but just zoom on the existing vector rendered at level 15) and using a pmtile vector tile format for ease of hosting (if it could also fit this need).

As you might see I'm a little bit confuse about your answer, could you provide me some guidance please?

---

UPDATE:
I also check configuration of felt/tippecanoe: Build vector tilesets from large collections of GeoJSON features. (github.com) and it looks like it supports creatin vector tiles up to zoomLevel=22. What would be the need for providing support for generating vector Tiles for z=22 if there is not data for such level of details? Is there any tradeoff/limitations that I didn't get from first pass on these oss projects?

---

UPDATE 2:
I have tested to download the prebuild basemap pmtile from Builds | Protomaps Basemaps and I see that even if the maxZoomLevel is limited 15, the overzooming to level 17 seems to fit my need.
I have used the following PMTiles Viewer (protomaps.github.io) tool to test the overzooming visualization and take the following screenshot:

[bdon]

Yes, the PMTiles Viewer as you have shown in the screenshot is displaying zoom level 17 using over zoomed 15 tiles. 15 is generally enough for POI and building-entrance level mapping.

[YohanSciubukgian]

Thanks for the confirmation.
I'll start with maxZoomLevel 15 with overzooming as you suggest it.

For my personal understanding, could you let me know what & where is the limitation from providing more detailed maxZoomLevel (> 15)? Do you have any link / github issue that I could learn more from?

[bdon]

See #266 and related issues

[joejuzl]

How difficult would it be to enable zoom 16 tile generation in planetiler?
I'm in a situation where tile size (in bytes) is a big factor, and where we are always displaying at high zoom levels. Being able to generate tiles at zoom level 16 would be very helpful.

Is it just the case of changing a variable from int to long? Or are there wide reaching implications in the code-base?

[msbarry]

The main constraint is that all features get sorted by a 64-bit key that gets encoded like this: https://github.com/onthegomap/planetiler/blob/main/planetiler-core/src/main/java/com/onthegomap/planetiler/collection/FeatureGroup.java#L110. There are 5.7 billion z16 tiles, which we only need one extra bit (33 total) so we'd just need to steal a bit from one of the other components.

[erik]

Not sure if this is a common use, but both @joejuzl and StrandedKitty in Slack were interested in a fixed zoom level at z16. I think we can already support that particular case, since z16 would have 4**16 == 2**32 tiles, which can fit into the 32 bits if no other levels are needed.

We'd need to adjust the logic for checking the min and max zoom bounds, but that might be the only necessary change?

[bdon]

IMHO the benefits of moving to true z0-z16 support outweigh the simplicity of ID-remapping workarounds that do only one zoom level.

QA tiles ( planetiler example ) which are used by some analytics apps are the main single-zoom application I know of.

[erik]

On second thought, yeah I agree. Not worth doing the hacky solution here. I was thinking this could be a nice stopgap until true z16 support is implemented, but other changes are required for this anyway (like some kind of hacky change to TileCoord)