SQL function for GEOSEqualsExact

[Mike Taves]

This enhancement request is to add an SQL function to access GEOSEqualsExact from the GEOS C API to find geometries that are equal, up to a specified tolerance. A suggested prototype would be:

boolean ST_EqualsExact(geometry A, geometry B, integer tolerance DEFAULT 6);

Although a name ST_AlmostEquals might better describe the desired operation, since it is designed to provide equality for inexact geometries.

External to GEOS, it is used in Shapely as ​object.almost_equals(other[, decimal=6])

[Mike Taves]

And as a footnote for Shapely's almost_equals, the decimal argument is translated to a tolerance (which is a float, not an integer) using 0.5 * 10**(-decimal).

So decimal=6 is tolerance=5e-07. I'm not sure which method is preferable.

[dbaston]

On one hand, this seems like a cleaner and more direct alternative to the ST_Equals(ST_SnapToGrid()) chain that's often used. On the other hand, I think it may introduce confusion in that it differs from plain-old equals not just in tolerance but also semantics. Here's an example I just tested in JTS:

Geometry g1 = LINESTRING (0 0, 1 1);
Geometry g2 = MULTILINESTRING ((0 0, 1 1));

g1.equals(g2) // true
g1.equalsExact(g2, 0) // false

(I'm assuming GEOS behavior is the same, here)

[robe]

Hmm interesting. Does it consider directionality? So maybe more a mirror of ST_OrderingEquals rather than ST_Equals? Though testing ST_OrderingEquals it no longer behaves the same as when I documented it eons ago. Not sure when this change happened.

[Mike Taves]

Replying to dbaston:

(I'm assuming GEOS behavior is the same, here)

Yes, I found this behaviour too. See ​https://trac.osgeo.org/geos/ticket/731

[robe]

Milestone renamed