Mixed winding order confuses MapNik renderer

[pramsey]

The complex polygon in this KML file has a mixture of winding orders, which cause MapNik to render the holes as filled (one hole is probably reversed relative to the others).

When the polygon is "fixed" by using ST_ForceRHR on it, it renders correctly (as seen above).

[pramsey]

Open question is whether it's worth fixing. The workaround is clear, and not too expensive in cases where this manifests, just wrap the geometry in ST_ForceRHR. Checking for this in every render would add overhead that would only yield an improvement in extremely rare cases (though I suppose the since the check would only be required in cases where # holes > 1 the check itself would only get run infrequently). However, orientation checking is not cheap (basically you calculate area and see if it's positive or negative).

[pramsey]

As a proof of the point, I was able to generate the same effect by creating a polygon with two holes, one clock-wise and the other anti-clock-wise.

[pramsey]

Actually, the problem seems to be having the exterior and interior rings with the same order. These rings all go anti-clockwise. So MapNik expects holes to always run counter to hulls? That seems like a big assumption, in a world of ugly data.

[pramsey]

This was canvassed in mapnik community https://github.com/mapbox/tilemill/issues/2110#issuecomment-75897323 and a fix applied mapnik#2371 (comment)
(maybe to the 3.x branch)

[pramsey]

For @rochoa to review. It's tiny, but it's really deep in the stack, could have some unexpected effects in unexpected places.

[rochoa]

Unexpected effects in unexpected places sounds like a doble negation, so ... what could go wrong?