[Django] #25650: `GEOSGeomerty.__eq__` should use `equals` not `equals_exact`
Django
--------------------------------------+--------------------
Reporter: sir-sigurd | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: GIS | Version: 1.8
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+--------------------
{{{
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
[https://github.com/django/django/blob/ab873e7a681e62d6803a3c04a051a47335f7b93a/tests/gis_tests/geoapp/test_functions.py#L433
this].
There is related [https://trac.osgeo.org/geos/ticket/731 ticket] in GEOS
trac.
--
Ticket URL: <https://code.djangoproject.com/ticket/25650>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: sir-sigurd | Owner: sir-
Type: | sigurd
Cleanup/optimization | Status: assigned
Component: GIS | Version: 1.8
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by sir-sigurd):
* owner: nobody => sir-sigurd
* status: new => assigned
* needs_docs: => 0
* needs_tests: => 0
* needs_better_patch: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/25650#comment:1>
Django
Reporter: sir-sigurd | Owner: sir-
Type: | sigurd
Cleanup/optimization | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by claudep):
* version: 1.8 => master
* stage: Unreviewed => Accepted
Comment:
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!
--
Ticket URL: <https://code.djangoproject.com/ticket/25650#comment:2>
Django
Reporter: sir-sigurd | Owner: sir-
Type: | sigurd
Cleanup/optimization | Status: assigned
Component: GIS | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by sir-sigurd):
Replying to [comment:2 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?
--
Ticket URL: <https://code.djangoproject.com/ticket/25650#comment:3>
Django
Reporter: Sergey Fedoseev | Owner: Sergey
Type: | Fedoseev
Cleanup/optimization | Status: closed
Component: GIS | Version: master
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Sergey Fedoseev):
* status: assigned => closed
* resolution: => wontfix
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/25650#comment:4>