To specify my POV, even z16 would be a huge leap forward if z17 or z18 were out of this world ask, any would help.

My main gripe is that z15 is not that zoomed in in very detailed areas like downtowns, it causes inefficiency in 2 ways:

• plenty of "peer" features are hidden due to density, could pre-sort them on generation and push some to z16
• plenty of features are just not that important (benches, trash cans, etc), would still like to have them but not in z15

I understand from another discussion that it's a limit of bits available. I don't have the full context, so I'm not sure how big number would be needed to go to z16, z17, z18, etc, I can only imagine there's a point where it becomes impractical for general use.

You can also use group/gridrank to set a "rank" field on the pois that ranks them by priority within a grid (see openmaptiles poi for example). Then you can use the filter maplibre layer property to limit what zoom level they show up at.

So the only benefit of generating tiles at higher zoom levels is if you know your style won't need features until z16 or 17+ you can omit them from z15 to reduce the size. But the cost is that when clients download the z16/17+ tiles they need to re-download features that were already included in z15, and your tile archive will also get much larger from the duplicate features. For example if a Z15 tile was 100kb, each Z16 tile in it would be ~25kb so you'd probably need to be able to reduce the Z15 tile by 25-50% for it to be worth it to also generate Z16.

Alternatively you could generate a separate high-zoom tileset and serve low-zoom tiles up to z14 or 15 and high-zoom tiles at z15/16+ so you don't need to duplicate all of the features from low zoom tiles into high zoom tiles to save client bandwidth. But the cost there is extra hosting and style complexity.

Thanks for writing down your ideas and suggestions.

Any ideas why second layer is not added? Minimal example gist is linked in my previous comment. That would be one possibly workaround, even though it would not satisfy my two reasons listed below, still better than nothing - some stuff is just not possible with maplibre styles.

Why z15+ is such a big deal for me.

Reduce the weight of z15

Not the most important benefit for me but still, very welcomed one. z15 would not be "heavy" tile if it wasn't the last zoom level and didn't include everything. z15 is still mostly the "find something/look around" zoom level for my use cases (dense locations), z15+ is more about delving into details, so I don't mind having some duplicate data (mainly landuse and roads which are duplicated in every higher zoom level anyway). For example 95% of POI for me would not be in z15 at all, only the most important ones and big landmarks.

Satisfy customisability needs

I make very custom maps and that's the main reason for me. Not only do I target hundreds of features per map by ID, manually edit details on the fly if needed and move ones that are a bit off from design, I use strategies like this for example: feature gets included on z10 (to show icon), name field is added on z12, some other field on z14, etc. All done by taking the surrounding features into account on each zoom level to produce the most pleasing outcome or what is specified. This was a wonderful workflow for my use case from z1 to z14.

This worked wonders for place names, macro details like big parks, beaches, bays, harbours, etc but as soon as I started with POIs that should either progress from z14 to z16/z17 or even start displaying on z16/z17 (shops, bus stations, benches, list is very long) - it became instantly apparent that z15 is not enough for my use case.

Alternative is to do maplibre style trickery and you need a lot of it, in terms of complexity, number of layers and lines of code.. Now not only z15 is heavy but style file is also enormous.. And CPU is crying. Also Java code now lives two lives - one logic for z1-z14 and the other for z15. Especially if I want to continue with same outcome past z15 (when to show name or do something else with another field on particular zoom level). In many cases it's not possible due to how maplibre limits where you can read zoom, etc which is totally understandable - I also prefer to do it on generation, not on client CPU. All that complexity is massive compared to the fact that a simple Java if would solve the issue, not only the same way but better - data is not included if it's not needed.

You can also use group/gridrank to set a "rank" field on the pois

I considered it but there's a lot of manual, very custom ranking, not just "all hospitals are more important than supermarkets". I could have ID->rank lookups in code but how about adding/showing name at particular zoom level? Or some other custom field that defines some kind of visual outcome in map? So much complexity there and not everything is possible with maplibre style spec.

Alternatively you could generate a separate high-zoom tileset

Separate tileset for high zoom is also very interesting idea and I did consider it (at least a variation of it), hence this issue. I wanted to generate separate layers that I only show with minzoom: 16 | 17 | etc. Separate layer/tileset seems like the best workaround right now with only few drawbacks, of which you mentioned some: Java generation code still lives two lives, still requires extra layers, a lot more very complex styling code, some things are not possible (e.g show name at particular zoom), extra generation and hosting, etc.

Just a tad bit disappointed that I found the perfect workflow but I will most likely have to abandon it for lower zooms. I understand that my use case is a niche in some way, planetiler is mostly used to generate whole world and micro-details are usually not that important, i.e in most cases you don't care if mall A shows instead of neighbour mall B in z14. I get it, even though it's sucks for me, a lot.