mapbox / feature-filter Goto Github PK

'in' filters are implemented with m, the number of elements in the filter, inline if statements. When calling the filter function while iterating over a list of features of length n this leads to O(m*n) run-time, which can be really slow.

It is very useful in many cases, providing capabilities to filter features by regex matching.

e.g.

// will match a feature whose prop0 matches pattern.
var filter = ['match', 'prop0', 'pattern'];

Could you add a license file? Thanks!

There's a stack overflow due to all of the filter elements being passed as arguments. This bug is more important if #8 is fixed because that opens up use cases where this could be useful.

I can't find anything about support for nested properties in the GL spec so I'm just curious if it's something you'd like to support.

Since a GeoJSON properties object can be any JSON I'd expect to be able to filter on nested properties as well.

Maybe something that would work like this?:

featureFilter([
  'all', [
    '>=', 'duration.min', 500,
    '<=', 'duration.max', 1000
  ]
])({
properties: {
  duration: {
    min: 530,
    max: 800
  }
}); // = true!

I realise the issue is possible conflicts with a key named duration.max in this case so maybe use a "magic key" similar to $type?

Obviously another solution to this would be to flatten the properties JSON using something like https://github.com/hughsk/flat but sometimes that's not an option.

Cheers!

The usage of the Function constructor in this module means that mapbox-gl-js upstream cannot satisfy the Content Security Policy unsafe-eval rule. For CSP-implementing sites, a non-eval'ing method would better.

Compiling a filter using new Function is computationally expensive. Lazily compiling filters avoids any cost for filters that never get used.

Steps to Trigger Behavior

Create a filter spec like so:
[ '==', 'highway', '*']

This sort of <key>=* spec is pretty common in OSM.

Expected Behavior

Filters all features that have the highway tag, irrespective of the value. So features having a highway=primary, highway=secondary, highway=residential or highway=<anything> would get filtered.

Actual Behaviour

They don't get filtered.

For whatever reason geojson-vt generates vector tiles with geojson properties mapped to the tags property. This module used to check for f.tags and it is still mentioned in the code comments but it was removed: #12 (comment) - looks like nobody could remember why it was there. It would be good to support filtering tiles generated by geojson-vt, either by changing geojson-vt to use properties (which would also require changes to vt-pbf) or changing this back to check f.tags too.