Custom filter functions

[indus]

Motivation

I want to visualize a big dataset that should get filtered depending on the records in an array property. The array has a variable number of timestamps that all belong to the very same geometry (the variable size of the array is the reason why I can´t split it to seperate key value pairs timestamp1, timestamp2, ... , timestampN).
With the current filter-functions it is not possible to get this kind of filtering done.
I already did a monky-hack to to give it a test and it works great (see "design" + disabling style validation ;-).
But I would wish this would come to mainline.

Design Alternatives

Is "do nothing" an option?

That is always an option. But I could think others would like custom filters as well. Some uses and posibilities I can imagine:

• using Math functions; e.g. Math.abs using the value as a filter but the sign determins the paint color (a lot of this is possible by preprocessing the data; but if I wouln´t have to I wouldn´t do)
• using string-functions like substring, lowercase, charAt, ....
• topographic relations (e.g. point features within a certain sector and distance from a center point; imagine a radar monitor)

Design

allow a new type of filter where the operator is custom and the value is a function-body as a string. Use the function-body directly in the createFilter function like so:

function createFilter(filter) {
   var fnBody = filter[0]=="custom"? filter[1] : `var p = (f && f.properties || {}); return ${compile(filter)}`
   return new Function('f', fnBody );
}

Mock-Up

{ //layer
id: "myLyr",
...
filter: ["custom","for(var i=0,d=JSON.parse(f.properties.d),l=d.length;i<l;i++) if( d[i]>1490338653308 )return true"],
...
}

// using it to set a "dynamic" timebased filter

map.setFilter('myLyr',["custom","for(var i=0,d=JSON.parse(f.properties.d),l=d.length;i<l;i++) if( d[i]>"+(+new Date)+")return true]"
// feature gets visible when at least one of its timestamps is in the future"

Concepts

How will we teach this design?

a short addition in docs. The only tricky aspect is that you have to know and trust blindly that f is there and it is the feature

What terminology will work best for the new concepts introduced by this design?

The name of the operator should be one of those (if there has to be one):

• ["custom", "<fnBody>"]
• ["fn", "<fnBody>"]

I like "fn" but I also think it is more easy to say "I use a custom filter-function" then "I use a fn filter function" or "function filter-function"

Implementation

How you would implement the design in Javascript?

as shown above but with some validation here and there.

It would be also a good thing to make the devs aware of...
A. The function gets called in a worker.
B. The feature is not just the plain JSON-object.
C. The filter-function should be a "pure function" and not too complex

BTW Thanks for your work.

P.S.: Cances are good that I will also want this for data-driven paint properties at some point ;-)

[indus]

Just found #4077 and realized you may not want that kind of solution because it is js-only and not cross-platform. Nevertheless I would enjoy.
Maybe it would be a solution to allow the use of custom filter functions during runtime only and use a serialized function that could get passed to workers in JS and user pointers to functions on other platforms.

[jfirebaugh]

Yes, we need to keep the style serializable as JSON for a variety of reasons. #4077 covers what we're likely to implement in this area.