[FEATURE] use a provided MapLibre stylesheet to prune unneeded layers and features from a profile

[jake-low]

It would be cool if you could provide a MapLibre stylesheet to Planetiler at runtime (e.g. --optimize-for-style=example.json), which would be used to prune unused layers, features, and attributes from the output tiles (reducing their size and making your map load faster).

I know this has already been discussed in a few places, e.g. on Slack, but I couldn't find an existing issue for it, and had some thoughts I wanted to share about implementation details, so I figured I'd open one.

I think this feature is made up of four specific sub-features, which I've ordered below by how difficult I think they would be to implement (easiest first).

1. Skip tile layers that are defined in the profile but aren't used by any style layer. This just requires looking at each style layer's source-layer property (which is always a plain identifier, not an expression), and skipping any tile layer that is not referenced anywhere.
2. At a given zoom level, skip tile layers that are not used at that zoom level. For example, if the profile defines a railways layer, but all style layers that reference this layer have a minzoom of 12, then the profile can skip emitting features into this layer at zoom < 12. Like source-layer, minzoom is always a constant (never an expression) so this is easy to check statically. It's probably worth adding symmetric handling for maxzoom too (skip tile layers at high zooms that are only needed by the stylesheet at low zoom), though that case is probably less common in practice.
3. Skip specific features that are not matched by any style layer's filter expression. For example, if the profile defines a shops layer which includes every OSM element tagged shop=*, but the stylesheet only renders specific shop types using a filter such as ["in", "shop", "supermarket", "department_store", "mall"], then features which do not match that filter could be excluded. This is harder because it requires evaluating arbitrary MapLibre filter expressions in Planetiler when building the tileset. Maybe MapLibre expressions could be translated into Planetiler's Expression types?
4. Omit attributes on features if those attributes are not used in the stylesheet. Planetiler would need to make sure that the attribute is not used for filtering (in a filter property on a style layer) or for data-driven styling (in an expression on a layout or paint property). This might be tricky since there are several expression variations to detect: the expressions ["in", "foo", "a", "b"], ["==", ["get", "foo"], "x"], ["has", "foo"] all use the foo attribute, plus there are legacy forms like "text-field": "{foo}" to worry about as well.

You could technically go even deeper (such as omitting specific attributes at low zoom that are only used by the stylesheet at higher zooms), but the list above is probably enough to cover a lot of common cases.

An additional thought: stylesheets can have several sources, so the CLI should probably offer a way to indicate which of the stylesheet's sources corresponds to the Planetiler profile being built. Maybe it could be optional in the simple case where the stylesheet just has one source.

[CommanderStorm]

The data savings are here quite significant.

OMT prunes well on sparse styles like americana or toner.
For example, if you just do the property/layer pruning (not looking at more advanced things, but looking at various dead conditions) I am getting 20-50% data size reduction on my research project.

I would recommend not supporting legacy forms since this way we get to push pressure on people to migrate their style ^^
We have tooling to migrate, this should be fine.

I only have two clarifications:

• for 4. This is only possible if a non-narrowble propertiesis not used
• you can also prune away geometrys relatively often, if all filters forbid it. This is a bit harder to get "just right", but running against our render tests can be a relatively good guarantee of correctness.

[CommanderStorm]

I have tried a few other transforms when it comes to, only pruning seems to be more effective than 1-2% when it comes to rendering perf.

Smaller data is a significant increase in FPS, tile load and all other metrics, so is one of those things that are "always" a good idea, unless you are building a data delivery platform and don't control the styles.

[mizmay]

Hey great proposal! Here's a presentation along these lines at SOTMUS in 2023.

From the era before Planetiler, here are some points from having done this in the wild / tried marketing "tile audits" to clients with their own internal tile pipelines:

1. At least back then, @jake-low's 1 and 2 options yielded the best results by far, getting more granular is appealing but there were plenty of low-hanging fruit (in the form of entire tile layers that were not in use)
2. Factoring in zoom is valuable for specific zooms: zooms ~6-13 tend to get the most crowded AND typically would be the ones users need e.g. for navigation, consider profiling what tiles are used for a few typical use cases to narrow this heuristic because you can reliably make the case that pruning in this range will be more impactful overall than at z5 (except in very special cases).
3. There is a special consideration around buildings and overzooming. I don't know how common this is any more, but it used to be pretty common to build tile pyramids only to z13, but not style them until z14 or 15, so pruning would skip them, but a very similar process/analysis could tell you it makes sense for performance reasons to build out another tile zoom so that you aren't overloading zoom 13 and making your end users download heavy tiles with buildings in them (that they will never see).

On the other end of the spectrum, last observation/question that of course I have not actually tested so tell me if Planetiler is so tuned this couldn't matter: this work is generally done assuming the data is already simplified and excess tile attributes dropped in the tile production pipeline, as this will make the MOST difference for a complex basemap, but for a simple custom stylesheet that drops most everything on the floor, why not prune first, simplify after?