Polygon approximate equality vs. exact equality.

Expected behavior and actual behavior.

I expected polygon1.almost_equals(polygon2) to always be true if polygon1.equals(polygon2) is true. That is, I expected approximate equality to hold if exact equality holds.

Actually, approximate equality might not hold when exact equality holds for polygons. This generalizes to multipolygons, and has to do with the order in which primitive parts are provided to the constructor.

Steps to reproduce the problem.

import shapely.geometry as g
import numpy as np

unit_square = np.array([(0,0), (0,1), (1,1), (1,0)])
unit_hole = unit_square * .5 + .25
smaller_hole = unit_hole * .25

# reverse the order of the holes
pgon1 = geom.Polygon(shell=unit_square, holes=[unit_hole, smaller_hole])
pgon2 = geom.Polygon(shell=unit_square, holes=[smaller_hole, unit_hole])

# both are valid
pgon1.is_valid
# True
pgon2.is_valid
# True

# The relates string matches the equality predicate:
pgon1.relate(pgon2)
# "2FFF1FFF2"
# They're equivalent:
pgon1.equals(pgon2)
# True
# But not approximately equivalent
pgon1.almost_equals(pgon2)

# likewise in multipolygons, rearranging the order of elements within a polygon or across 
# elements of the multipolygon keeps equality but breaks almost-equality
mpgon1 = geom.MultiPolygon([pgon1, geom.Polygon(unit_square + 1.1)])
mpgon2 = geom.MultiPolygon([pgon2, geom.Polygon(unit_square + 1.1)])
mpgon3 = geom.MultiPolygon([geom.Polygon(unit_square + 1.1), pgon1])
mpgon4 = geom.MultiPolygon([geom.Polygon(unit_square + 1.1), pgon2])
mpgons = [mpgon1, mpgon2, mpgon3, mpgon4]

almost_equal_table = [[mpgon.almost_equals(other_mpgon) for mpgon in mpgons]
                       for other_mpgon in mpgons]
print(np.array(almost_equal_table))
# array([[ True, False, False, False],
#       [False,  True, False, False],
#       [False, False,  True, False],
#       [False, False, False,  True]], dtype=bool)

equal_table = [[mpgon.equals(other_mpgon) for mpgon in mpgons]
                for other_mpgon in mpgons]
print(equal_table)
# array([[ True,  True,  True,  True],
#        [ True,  True,  True,  True],
#        [ True,  True,  True,  True],
#        [ True,  True,  True,  True]], dtype=bool)

Operating system

GNU/Linux (4.13.1-1-Arch)

Shapely version and provenance

version 1.6.1 installed from pip.

Comments

More of a question-issue than a bug-issue… is this intended behavior?

If this is intended behavior, it makes sense from an implementation perspective; doing pairwise approximate comparisons between primitives to figure out which part was approx equal to any other part wouldn’t be fun. That said, I think disclaiming this in the docstring of almost_equals might reduce surprise. I figured it’d behave like equals, like a fuzzed/buffered contains & within.

[ljwolf]

Will do. Should land by EOD Friday.

On Thu, Oct 26, 2017, 18:01 Sean Gillies [e-mail] wrote:

@ljwolf https://github.com/ljwolf we’d greatly appreciate such a PR! Can you aim it at the maint-1.6 branch? I’ll pull it from there into master.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/Toblerity/Shapely/issues/535#issuecomment-339732114, or mute the thread https://github.com/notifications/unsubscribe-auth/ACJY82MaAoTv1pveW_ULCywZAkRvjMBFks5swLrUgaJpZM4QGquO .

– Levi John Wolf Lecturer in Quantitatve Human Geography | University of Bristol Associate Member | Center for Multilevel Modeling, University of Bristol Visiting Fellow | Center for Spatial Data Science, University of Chicago ljwolf.org

[sgillies]

Closed via #537.