Does the method #cureLocalIntersections in the Tessellator make any sense?

Description

I have always been confused by this method which claims to fix self-intersections of the polygon but we require in the Tessellator java docs that polygons should not have self-intersections. More over, we have no test that needs this method to pass so it is currently untested / unnecessary.

I am bringing this up because I have an example of a polygon that it seems to spend half of the time on that method. It is a huge polygon that with this method takes around 560 seconds to tessellate but 260 seconds if we don’t go through this method.

My proposal is to remove the method completely or at least not call this method if the Tessellator has been called with the flag checkSelfIntersections set to true.

@nknize introduced this method on the first version of the Tessellator, he might have more background about the need of this method. what do you think?

[iverase]

Then let’s just skip that step if the tessellator is called with the flag checkSelfIntersections set to true. In that case it will fail before getting to this place.

[nknize]

I don’t understand this. We re claiming in the java docs that polygons should not be self-intersecting and we do not introduce self-intersections in our code, why we want to remove them?

Because real life Geo data doesn’t care what our javadocs say. Small self intersections are a reality that rears its head every now and then in real data and the performance hit to “best effort” detect and clean in the tessellator’s cure phase at index time was worth more than directing user’s to a third party cleaning utility before indexing.

Our blind polygon class does nothing to enforce those javadocs so maybe before completely removing we might consider flagging that phase as an optional validation step disabled by default? (Think ignore_malformed)