`GEOSGeomerty.__eq__` should use `equals` not `equals_exact`

[Sergey Fedoseev]

In [1]: from django.contrib.gis.geos import LineString

In [2]: LineString((0, 0), (1, 1)) == LineString((1, 1), (0, 0))
Out[2]: False

in psql

SELECT ST_GeomFromText('LINESTRING(0 0, 1 1)') = ST_GeomFromText('LINESTRING(1 1, 0 0)');
 ?column? 
----------
 t
(1 строка)

Using equals in __eq__ will allow to get rid of some quirks in tests, such as ​this.

There is related ​ticket in GEOS trac.

[Claude Paroz]

See also the discussion on #25446. The difficulty here is to find an acceptable compatibility path and to take into account backend differences. Feel free to try!

[Sergey Fedoseev]

Replying to claudep:

See also the discussion on #25446. The difficulty here is to find an acceptable compatibility path and to take into account backend differences. Feel free to try!

GEOSGeometry also supports comparison with WKT strings, which works like this:

In [25]: Point(0, 0) == 'POINT (0.0000000000000000 0.0000000000000000)'
Out[25]: True

In [26]: Point(0, 0) == 'POINT (0 0)'
Out[26]: False

I think that it would make behavior more consistent if __eq__ created geometry from WKT string and then used it for comparison, from other hand I think that comparison of different types is not pythonic at all. What do you think about this?

[Sergey Fedoseev]

After a while I think the current implementation is OK because if we want to compare "spatially" we need to transform both geometries to the SRID which will inevitably lead to computational error.