Add intersection decision operator(s)

[quincylvania]

Design Proposal: Add intersection decision operator(s)

Motivation

Over at osmus/OpenTrailMap we're adding the ability to filter trail data to a specific park. In MapLibre we can filter POIs easily with the within operator. However, we also want to filter trails. within works for lines, but it will exclude lines that are not strictly contained, so we would lose any that cross the border of the park.

Proposed Change

Adding one or more spatial relationship operators dealing with intersection would fulfill the need, namely intersects (the boundary and interior of the feature intersects the boundary or interior of the other).

API Modifications

Add one or more decision operators.

Migration Plan and Compatibility

The feature would be purely additive and does not impact current users.

Rejected Alternatives

We could buffer the bounding feature a bit before applying within, but we'd risk losing very long lines, and we might include cruft we don't want. We could theoretically preprocess trails to split them at park boundaries when rendering tiles, but that seems like overkill. We could not filter lines at all, but that sort of defeats the purpose of focusing on a specific park and looks messy. In the below example, POIs are filtered to the dark green area while trails are not.

[HarelM]

Why not create a query to a server to get the relevant line and show them?

[quincylvania]

@HarelM What do you mean? The map data is all in Protomaps format. We don't query a server for specific data we just pull down tiles.

[HarelM]

Ahh, interesting.
The proposal makes sense, but how would we be able to not implement all the spatial operator going forward? Is there maybe an easier alternative by using some spatial libraries on query render features for example? or query source features?

[quincylvania]

how would we be able to not implement all the spatial operator going forward?

There's no need to implement them all unless there is demand and it can be done performantly. It just seems strange there would be a "overlaps completely" operator and no simple "overlaps" operator.

Is there maybe an easier alternative by using some spatial libraries on query render features for example? or query source features?

If you're asking whether I can just query the source layers for trails, run them through an intersection function outside MapLibre, and then filter them manually based on their ID or something… I guess so, but this seems like re-implementing filter functionality with worse performance.