Incorrect behaviour of the algorithm responsible for filling the polygon (EditableGeoJsonLayer)

[stuymedova]

Reproduction steps:

• Draw out a polygon in the DrawPolygonMode
• Switch to the ModifyMode
• Modify the polygon such that the edges overlap forming an hourglass

Expected behaviour:

• The two triangles of the hourglass are filled

Actual behaviour:

• The filling is lacking an edge

[donmccurdy]

I believe deck.gl expects that the defined curve has a consistent “winding order”, you'll see a similar result on https://geojson.io/ and https://play.placemark.io/. Rendering relies on concepts like the nonzero rule and back-face culling.

If you were to load these points...

D    A

B    C

... in a 3D viewport and view from all sides, I think you'd see the renderer draws two triangles, ABC and CDA (or similar), with ABC facing up and CDA facing down. If you want to draw both sides of all triangles, you can disable back-face culling, but the result will still be a bit different from the hourglass you describe. For that I think you would need a more opinionated interpretation of the polygon.

[felixpalmer]

Agree with @donmccurdy, this is expected behavior. Imagine you had a fence surrounding a house, painted white only on the side enclosing the house. The side defines the "inside" of the shape. If you drag the fence to make an hourglass, the white side is no longer enclosed, and thus the fence no longer encloses an area, in other words it is not a valid polygon.

If you need to draw an hourglass, you need to trace both polygons with the same winding order

[stuymedova]

We're using the popular turf.js library to filter data points so that only the ones within the polygon are included, and we get an hourglass behaviour there. Is it possible to configure or swap out from the outside the algorithm responsible for the calculation?

[stuymedova]

Or, alternatively, there is a setting called preventOverlappingLines. It would be great to enforce this behaviour when the user is editing the polygon as well. For instance, when the user lifts up the mouse key we could check for the overlap, and if so, a vertex could go back to where it was before the user started dragging.