Attribute-driven min feature zoom

[msbarry]

I have a use-case where I want to set a fractional "min zoom" attribute on individual features so as you zoom in and out, the feature is visible above that zoom and invisible below it. I don't think there's a way to do this in off-the-shelf maplibre so in the past I've done this in a fork by tweaking the shader but I'm wondering if it would make sense to add as a feature to maplibre.

Ideally I'd be able to do something like:

'circle-minzoom': ['get', 'minzoom']

and that minzoom would get included in the feature's data passed to the gpu and the shader would handle conditionally showing/hiding the feature by comparing to zoom scalar.

A few things I tried using existing style spec:

'circle-opacity': [
  'case',
  ['>=', ['zoom'], ['get', 'minzoom']], 1,
  0
]

but it fails with error:

Error: layers.point.paint.circle-opacity: "zoom" expression may only be used as input to a top-level "step" or "interpolate" expression.

or:

'circle-opacity': [
  'step', ["zoom"],
  0,
  ["get", "minzoom"], 1
]

but it fails with:

Input/output pairs for "step" expressions must be defined using literal numeric values (not computed expressions) for the input values.

Does anyone have any other ideas to try for doing this with existing features? Or if not then what do people think of the proposed *-minzoom style spec addition?

[HarelM]

We are doing this in the "data level" i.e. when building the tiles we select which features to include in the tiles and which not to include, why not solve it this way?

[msbarry]

That sounds good, do you have a sense which of the ones I tried (or a different one) would be ideal to try to get working? My only concern would be if there's some reason deep down that makes one of those options not viable...

[HarelM]

I honestly don't know. I would guess that these were not implemented only due to relevant use case not tested, not anything deeper.
I would suggest to post here a few possibilities and see which one the people here think is the best and try and implement it. If there's a problem with implementation, I would then go and try implementing the second favorite option. But up to you how to proceed with this, this is just my personal suggestion on how to move forward.
Thanks for all the time and effort you put into this! Truly appreciated.

[pnorman]

I suspect layout properties are only evaluated at integer zooms for performance reasons and for stability of features as you zoom in and out.

[msbarry]

From what I can see to get step/interpolate working with data-driven zoom stops you would need to compute the stops then pass them down in a uniform and compare them in the shader, and each shader would need support for each kind of attribute you can control with this mechanism.

Another option would be to just implement enough support for very basic minzoom/maxzoom cases using the existing step syntax. So the cases of ['step', ['zoom'], 0, ['get', 'minzoom'], 1] or ['step', ['zoom'], 1, ['get', 'minzoom'], 0] would go from being invalid to supported.

[HarelM]

I would consider adding support for the use case you need and not "for everything", unless it's almost the same code-wise which doesn't sound like it from what you described.
Having said that, I would try and avoid defining new syntax or keywords and stick with what currently exists, hopefully.
I hope that makes sense...

[wipfli]

@maxammann and I were discussing the other day that expressions are evaluated on the CPU and only at integer zoom levels. The interpolation at the fractional zoom levels is then done on the GPU. I guess this is for performance optimization.

@maxammann you said that you can confirm that the shaders only do the interpolation?

[wipfli]

Ah interesting, so the full expressions for paint properties are evaluated on the GPU?

[IvanSanchez]

As far as I'm aware, yes.

Keeping in mind that my knowledge of maplibre's internals is lacking, I'm guessing that the original problem is that maplibre-gl-js has incomplete support for translating paint expressions into shader code.

[maxammann]

Expressions are always evaluated on the CPU. With evaluation I mean a function of fn evaluate(expression: JSON) -> number | fn interpolate(min: number, max: number: zoom: number) -> number.

The trick maplibre uses to make expression dependent on the zoom is that they evaluate the returned function on the GPU. That function is only interpolating linearly between two values though.

maplibre does not translate expressions to shader code in any way.

---

Bottom line: It's hard to say that expressions are only evaluated on the GPU or CPU. Render tricks are all over the place and make sure that expressions do not impact the render performance.

[maxammann]

Here is some more background information: https://maxammann.github.io/maplibre-internals/architecture/Expression-Architecture.html

[wipfli]

Cool

[msbarry]

I ended up going with the fork approach for speed of implementation, here's a demo of what the result looks like comparing each feature against it's minzoom to decide whether to show it in the shader: https://msbarry.github.io/maplibre-minzoom-demo

[msbarry]

and just for fun, here's the same approach applied to 486k placenames from the whole planet with labels bucketed into zoom levels and served using pmtiles: https://msbarry.github.io/maplibre-minzoom-demo/world.html

[wipfli]

Such a cool map

[wipfli]

@msbarry can you maybe share the source code of your attribute-driven minzoom implementation? I would like to test it with my map style...

[msbarry]

Sure thing - here's the diff: msbarry@bf3b8de

[wipfli]

Thanks!

[adjourn]

I ran into similar situation.

Since the MVP (most valuable player, not minimum viable product) of data generation planetiler has max zoom 15, there's a lot of stuff there and a big portion of it should be shown at zoom 16 (or even 17). Obvious solution with that limitation is to include minzoom attribute to features on zoom level 15 which I'm definitely going to do.

While I could benefit from other features as well, most obvious one would be text-minzoom for me instead of messing around with visibility or text-opacity.

The unfortunate outcome is that all zoom levels pay the price, although the minzoom variable exists only on zoom level 15.

[adjourn]

Okay, time to laugh at myself, took me few hours to experience what was already discussed here.. You CAN'T use zoom to match feature minzoom property in order to set text-opacity/visibility. And it seems you can't set layer minzoom dynamically.

Or has there been any advances in style spec to somehow achieve it?