Opened 8 years ago

Closed 7 years ago

#25650 closed Cleanup/optimization (wontfix)

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

Reported by: Sergey Fedoseev Owned by: Sergey Fedoseev
Component: GIS Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Change History (4)

comment:1 by Sergey Fedoseev, 8 years ago

Owner: changed from nobody to Sergey Fedoseev
Status: newassigned

comment:2 by Claude Paroz, 8 years ago

Triage Stage: UnreviewedAccepted
Version: 1.8master

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!

in reply to:  2 comment:3 by Sergey Fedoseev, 8 years ago

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?

comment:4 by Sergey Fedoseev, 7 years ago

Resolution: wontfix
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.
Back to Top