ST_MakeValid changes the order of points in a polygon

[atiannicelli]

I think that all polygons in OSM and other datasets are supposed to be ordered in such a way that the points in the polygon are listed in counter clockwise direction.

Here is an example. I gave it this polygon:
POLYGON ((10.947076 45.9679118, 10.9471748 45.967871, 10.9472574 45.9679588, 10.9471571 45.9680032, 10.947076 45.9679118))

And asked it to apply ST_MakeValid on it and it gave me this:
POLYGON ((10.947076 45.9679118, 10.9471571 45.9680032, 10.9472574 45.9679588, 10.9471748 45.967871, 10.947076 45.9679118))

Here is a picture of that polygon with the first (and last) node highlited.

Here is a picture of that same polygon with the first and second point of the original polygon highlighted showing that the order indicates that it is counter-clockwise - This is correct!

Here is a picture of that same polygon with the first and second point of the polygon that was created with ST_MakeValid highlighted showing that the order indicates that it is clockwise - This is Wrong!

[james-willis]

You are right that exterior rings should be CCW. IME having them CW is typically not an issue.

Which version of sedona/jts are you using? Does this repro in JTS 1.20?

Can you repro the issue in JTS and file a bug there? If you do, please link back to here.

MakeValid just wraps the JTS GeometryFixer class: https://github.com/apache/sedona/blob/master/common/src/main/java/org/apache/sedona/common/Functions.java#L1126

As Jia mentioned on Discord, you can probably use ST_ForcePolygonCCW to work aroudn this issue for now.

[atiannicelli]

I'm not sure the jts version. I'm running in AWS glue 4.0.
I am specifying the jts.overlay=ng
Sedonda version was 1.6.1 when I hit the issue.

I've since upgraded to 1.7.0 and I'm using the new ST_RemoveRepeatedPoints to do what I was trying to accomplish with the ST_MakeValid function.

[james-willis]

I'm not sure the jts version.

sedona 1.6.1 is JTS 1.19: https://github.com/apache/sedona/blob/sedona-1.6.1/pom.xml#L74

I am specifying the jts.overlay=ng

This shouldn't matter, that should only affect ie intersection, union, etc calls.

It would be good to test this behavior in JTS 1.20 and file a bug in that repo. I searched past issues there and didn't find anything.