Open jorisvandenbossche opened 3 months ago
The implementation of equals
ultimately relies on s2geometry's S2BooleanOperation::Equals
, which provides a precision option. Unfortunately Precision.SNAPPED
is not yet implemented, but I guess it would still be possible to add some tolerance by passing a snap function to the Options
constructor (e.g., IntLatLngSnapFunction or IdentitySnapFunction with a given snap_radius
). We could do that in Spherely by customizing
In terms of API, I see that shapely also provides equals_exact
. I'm not sure how they behave exactly for point geometries, though. Would it make sense in spherely for equals
to have some internal minimal tolerance set by default so that the example above works, and provide a separate equals_exact
function that accepts a user-defined tolerance?
Something I ran into while testing https://github.com/benbovy/spherely/pull/20 (xref https://github.com/benbovy/spherely/pull/20#discussion_r1141150124), is that it is not that easy to pass an exact equality test with
equals()
.Illustration:
What I assume is happening here is that the roundtrip from
S2Point
toS2LatLng
and back is not exact (the conversion from S2Point to LatLng essentially happens in the WKT repr or in get_x/get_y, and the conversion from S2LatLng to S2Point is essentially happening in thePoint(..)
constructor.While that might be expected based on knowledge of the S2 internals (how a S2Point is stored, which is not as its lon/lat coords), I suppose this will not be expected in general by users? And it also gives some usability issues (also when testing)
For
equals()
specifically, it might be possible to have an option there to snap round coordinates while checking equality.