ST_MakeValid changes the order of points in a polygon
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!
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.
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.
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.