Opened 9 years ago

# SQL function for GEOSEqualsExact

Reported by: Owned by: Mike Taves pramsey medium PostGIS Fund Me postgis master

## Description

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])

### comment:1 by Mike Taves, 9 years ago

Version: → trunk

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.

### follow-up:  4 comment:2 by dbaston, 9 years ago

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)

### comment:3 by robe, 9 years ago

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.