Enable Within Expression with paint property + Filter Expression

[zmiao]

This pr introduces a new expression type within. Currently the usage is: [within, geoJSONObj]. It returns true if the feature is inside the geometry boundary that defined by geoJSONObj. geoJSONObj should be inlined.
This pr also enables the usages of setting paint property and filter expression with within expression. Following example shows how to set different color based on the feature's geometry location.

{
        "id": "circle",
        "type": "circle",
        "source": "points",
        "paint": {
          "circle-radius": 5,
          "circle-color": ["case", ["within", {
            "type": "Polygon",
            "coordinates": [
                [
                    [
                      0,
                      0
                    ],
                    [
                     0,
                     5
                    ],
                    [
                      5,
                      5
                    ],
                    [
                      5,
                      0
                    ],
                    [
                      0,
                      0
                    ]
                ]
            ]
            }],  ["rgb", 153, 128, 250], ["rgb", 249, 138,175]]
        }

With the variation of geometry types, there would be different within cases, like point within polygon, line within polygon, polygon within polygon, etc. Right now we only support point/points within polygon/polygons.

[pozdnyakov]

Do we have tests for the new expression?

[mourner]

like point within polygon, line within polygon, polygon within polygon

@zmiao do you anticipate extending within in the future with "within X meters from line" type queries, or would that be a different expression? If within will always act against polygons, maybe it's worth dropping the object wrapper (which will always be the same) and accepting coordinates directly.

[mourner]

Here, you return a result immediately if you're inside the first ring, even if subsequent holes negate that result — this leads to incorrect results with holes.

Another small gotcha is that GL Native resolves overlapping rings in a polygon with an even-odd rule instead of a non-zero one, so you want to return true if wn is even, not necessarily zero.

If so, you could remove the branching into two loops and simplify the code — here's an example from one of my library of the same routine: https://github.com/mapbox/which-polygon/blob/master/index.js#L81-L95

[mourner]

One more point — the naming pointWithinPolygons is a little misleading, since you're testing against a single polygon which has multiple rings (an outer ring and holes), not multiple polygons.

[zmiao]

fixed!

[zmiao]

@zmiao do you anticipate extending within in the future with "within X meters from line" type queries, or would that be a different expression? If within will always act against polygons, maybe it's worth dropping the object wrapper (which will always be the same) and accepting coordinates directly.

@mourner In our initial plan, we planned to implement the within covering all the geometry types. Right now, we will start with polygon as it is required urgently. It is not necessarily to be within X meters from line, we could check if a point is on a line, line lies on lineString, etc.
And further more, it is not flexible to use inlined geojson source, in the future, we plan to have mechanism that could read from url and share the geojson source with all within expressions, in stead of saving geojson inside every expression.

[mourner]

The algorithmic fixes look 👍 (will leave the C++/native-specific code for others to review)

[alexshalamov]

lgtm, +changelog