Support for bitwise operations or bitsets?

[ianthetechie]

Background

I am doing some experiments with visualizing routing graphs built from OSM data. I believe that MapLibre + vector tiles are the perfect way to ultimately publish such work for the world. When looking a routing graph, one of the most important pieces of information is "can I access this road."

One of the ways that access restrictions can be represented is by "mode of travel" (ex: automobile, truck, bicycle, golf cart, etc...). The Valhalla routing engine cleverly encodes this as an integer using a technique familiar to C programmers, where each bit represents a mode of travel. Valhalla presently supports 12 modes of travel, and you can determine which modes are obviously allowed/not allowed for an edge by doing a bitwise and.

My end goal is to use MapLibre's dynamic styling to restyle the map based on allowed access (theoretical UX: the user selects which modes of travel they are interested in and it shows roads which are legal/illegal for routing).

Problems doing this today

I don't think it needs any further discussion that the Valhalla representation is the most efficient way of representing this sort of set membership. So let's explore a few alternatives I've looked at and why I don't think they work.

Storing the number and crafting a match, in, or similar expression dynamically?

This does not scale. Consider the case of just 3 modes of travel: car (= 1), bicycle (= 2), and pedestrian (= 4). To create a style expression that matches features traversable by bicycle, you would need to match on 4 numbers (1, 3, 5, and 7). When you have 4 travel modes, you'd need 7 cases, and so on...

Storing a list of access values and treating them like a set?

I think MapLibre has support for list membership checks via the in expression (I haven't used it but if I'm reading the docs right, this would work?). However, my understanding of the MVT spec is that you cannot store anything besides strings, integers, and boolean values. So I suspect this will not work unless MapLibre can do some coercion that I'm not aware of.

If this is possible, please let me know. The idea would be to store every valid "bit" (ex: 0, 1, 2, 4, ...) OR alternatively to just store a string repr. The latter is more friendly, and IIUC the MVT spec stipulates that byte-for-byte identical values should not be stored multiple times in a tile. So if this is possible, I think it's actually a reasonable approach. The question is whether it's possible to get a property as an array.

Variant hack: I could also store each variant as a single character(?). This might be a bit more limiting, would definitely be more confusing, and would be slightly less space efficient, but for my use case it would probably be acceptable in case nothing comes out of this discussion.

Ideas to discuss

At a lower level, adding support for bitwise ops should not be that contentious at a theoretical level. We already have more math like logarithms built-in. I presently only have need of bitwise and (&), and have not considered whether other operations would be useful. In this case, you could bitwise and any two numbers, and you can decide what to do with it. This is pretty simple and would cover obvious use cases.

Given that, I wonder if thinking explicitly in bitset terms instead is actually more useful. It certainly would be for my use case. I believe the most useful operations are disjoint (the inverse of which tells you if there is an intersection at all), and sub/super-set checks. This is slightly more complicated and would surely require additional community discussion, but it might enable more powerful use cases than what's top of mind.

Thanks for the consideration; let's have some discussion :)

[HarelM]

I think you can encode the access using characters - h for hiking, b for biking, c for car, t for truck, etc...
It's not great, but I personally find bit-wise operations a good way to obscure things. I definitely prefer text where possible.
But it might just be me.
I don't think it's a problem from an implementation perspective...