[postgis-devel] ST_Normalize issues (was ST_Reverse issues)

[Paul Ramsey]

> On Jun 24, 2021, at 8:44 AM, Sandro Santilli <strk at kbt.io> wrote:
> 
> On Thu, Jun 24, 2021 at 08:36:25AM -0700, Paul Ramsey wrote:
>> https://github.com/libgeos/geos/blame/main/src/geom/LineString.cpp#L320
>> 
>> It means that for closed rings, the starting point is set to the lowest (? uniqueCoordinates->minCoordinate()) coordinate and the ring orientation is forced to CW. 
>> And I was wrong about the why, it was not for PostGIS regression, which I guess had few enough tests and didn't exercise the overlay differences very hard, it was for GEOS regression in the period when both overlay engines were fully in play.
>> Why make such a change? I didn't think normalize was used for anything other than regression tests, so it seemed not unreasonable to add this extra set of rules for this narrow case in order to achieve consistency in the tests between overlay engines.
>> To the extent that the old overlay engine is considered completely deprecated, the normalize behaviour could be removed and the tests updated to match the outputs of the NG engine. That wasn't really quite the head space we were in, even when releasing 3.9, so the more invasive normalize went into release as well.
> 
> The problem I'm having is actually that I *am* using it for regression
> tests, but the tests are running against both GEOS-3.8 and GEOS-3.9,
> so they always fail in one case and succeed in the other case.
> 
> The concept of a "canonincal form" was meant exactly to avoid this.
> This change is basically changing the "canonical form", which makes
> it useless (not canonical anymore). This is for projects which *use*
> PostGIS but are not part of it.

The idea that the one True Canonical Form was understood in its entirety in some early era and should/could never be changed is not really one I agree with. I found a new case of ambiguity and disambiguated it. If you remove the normalize behaviour you will instead at some point find yourself dealing with the fact that the NG and traditional engines return different linestrings on output from the same input. 

I'm fine for you to revert the behaviour, you'll also have to match the regression cases in GEOS to the NG output. It means we cannot turn overlay back to traditional and still pass regression, but I'm fine with that, old overlay is on the way out.

P.