FeatureLayer in sceneview renders polygons wrong

[JayHill]

I have drawing issues with a featurelayer(polygons) only when in sceneview though. There is no problem when using mapview. You can see the problem in this jsfiddle.

The polygons in the NE corner of the quad are colored as green down near the colorado river. They should be red. Like the small ones in the extreme NE corner.  Changing to MapView in the code resolves the issue. Perhaps a bug?

[GreteSoosalu]

Hi @JayHill 
Looks like a bug indeed, thanks for reporting! 

Btw results differ in MapView and SceneView because, in case of large and complex polygons, the API uses different algorithms for 2D and 3D to determine the fills and holes. 

We'll investigate it. 

[JayHill]

Has this been issued a bug number @GreteSoosalu ?

[GreteSoosalu]

Hi @JayHill  We've investigated this (and yes, it has an issue number). What we found out is that it is not a bug per-se but rather a limitation of the algorithm used for 3D, and therefore there's no quick fix.

Aligning the behavior in 2D and 3D for such datasets is in our backlog but not yet planned for a release.

[JayHill]

@GreteSoosalu Just curious what about the data that makes the algorithm choke on this data and none of our other data?

[GreteSoosalu]

Good question. The algorithm used in 3D gives unexpected results in case a polygon: 

1. either is self-intersecting
2. or contains holes that do not respect the counter-clockwise winding rule

A workaround can be to simplify and republish the data. For single/separate geometries, the Maps SDK for JavaScript offers geometryEngine.simplify function but in case of a whole layer, I'd rather go for preparing the data on desktop and republishing. 

PS: during the investigations, we managed to fix some issues and inconsistencies how complex polygons are rendered in 3D, but I couldn't detect improvements in the test app/data you shared with us.  

Those fixes are released in the upcoming (4.28) release and you can test it out on our development /next version of the API. I hope that this in combination with republished data can help you further.

[JayHill]

could you explain the counter-clockwise winding rule?

[GreteSoosalu]

Hi again and thanks for your patience, 

As the polygon geometries are encoded as a series of rings, the filled rings must have vertices in clockwise order, whereas the vertices of the holes must be counter-clockwise.

Also, the order of all the rings (filled ones and holes) matters: the FIRST ring is considered as filled, followed by N number of holes; then another filled ring and its holes should come, etc. This means that if the first filled ring's holes are ordered after the second filled ring, those won't take effect (see example here: https://codepen.io/gsoosalu/pen/jOXzjWR). 

PS: also note that the poylgon geometries shouldn't have any overlapping edges, e.g. a hole's edge shouldn't intersect nor overlap a filled ring's edge.

Hope this explains a bit better how the geometries are currently interpreted in 3D. 

[JayHill]

@GreteSoosalu What is the bug number for this? It seems it is still an issue with 4.28 and next.

[GreteSoosalu]

Hi @JayHill 

Are you testing with the same app/data you shared here initially or it is still the problem after simplifying & republishing the data?

For 4.28, we managed to fix some issues (BUG-000147177) and inconsistencies how complex polygons are rendered in 3D, but I couldn't detect improvements in the initial test app/data you shared with us.

That's why we recommended to prepare (simplify) the data on desktop again and republish it.