Potential bug in the ST_Equals function.

[Wenjing]

Consider the following test case:

SELECT ST_Equals(Foo.a, Foo.b), ST_Distance(Foo.a, Foo.c)
    FROM (SELECT ST_GeomFromText('LINESTRING(2 0, 0 1)') As a,
    ST_GeomFromText('LINESTRING(2 0, 0.2 0.9, 0 1)') As b,
    ST_GeomFromText('POINT( 0.2 0.9)') As c) As Foo; -- expected: {t}, actual: {f}

The distance from point c ('POINT( 0.2 0.9)') to line a ('LINESTRING(2 0, 0 1)') is 0. Line b ('LINESTRING(2 0, 0.2 0.9, 0 1)') is plus.

Line a should equal line b because they have the same points set. { (x,y) | 2*x + y = 0 }

Actual behavior: PostGIS doesn’t consider LINE a to be equal to LINE b. The result of st_equals is false which means Postgis doesn’t consider they are the same line, although the distance between them calculated is 0.

The issue cannot be reproduced with integers only, indicating a potential floating-point issue. After all coordinate points are magnified ten times, the results are in line with expectations.

Additional Information​https://tarry-goal-613.notion.site/Potential-bug-in-the-ST_Equals-function-398b8876ee9842219cb872e7eb7bb546?pvs=4

[mdavis]

Ironically, this bug is due to the high-precision evaluation of the line-point orientation predicate in GEOS.

Not sure what a suitable fix is at the moment. Likely it will involve some sort of precision rounding, but that needs to be done carefully to ensure there are no other impacts.

See also ​https://github.com/libgeos/geos/issues/968