Make geometries hashable (again)

[mwtoews]

It just occurred to me that with #960 to remove mutable geometries that we can restore hashable geometries.

This PR reverts #320 / e7ab27e (which also had tests that always passed).

Is there anything new to consider?

See also #209 with xrefs to relevant open issues to geopandas

[coveralls]

Coverage remained the same at 82.019% when pulling 1592303 on mwtoews:hash into 1d734de on Toblerity:shapely-2.0.

[mwtoews]

The hash strategy used before, and again here, just uses the object hash. This means that two equal geometries would have a different hash, which may not be expected. Should we consider improving the hash strategy on (e.g.) WKB?

[jorisvandenbossche]

The hash strategy used before, and again here, just uses the object hash. This means that two equal geometries would have a different hash, which may not be expected. Should we consider improving the hash strategy on (e.g.) WKB?

Yes, I think equal geometries (but not identical objects) should have an equal hash, ideally. So using WKB seems to be the way to go, although this also gives problems like linearring/linestring not being distinguishable (although we could hash the type id together with the wkb).

Now, this WKB-based hashing is already implemented in the base pygeos Geometry: https://github.com/pygeos/pygeos/blob/a12477f93f9cdb1ed80731ac3fc26059ec1096f2/src/pygeom.c#L116-L150
So if we keep this PR for after #983, the geometry classes will automatically inherit this hashability. And then the update to the tests of this PR is still useful.

[sgillies]

@jorisvandenbossche I think it would be a mistake for shapely geometry object hashes to be special and unlike ordinary Python object hashes. Geometry objects might "inhabit" the same part of space but be different things and we'll get collisions when constructing dicts and sets if we treat spatially-coincident objects as the same object.

[jorisvandenbossche]

a mistake for shapely geometry object hashes to be special and unlike ordinary Python object hashes.

It depends to what you compare. Most python objects don't use object.__hash__. For example, two tuples that are equal also have an equal hash:

In [12]: t1 = (1, 2) 

In [13]: t2 = (1, 2)

In [14]: t1 == t2  
Out[14]: True

In [15]: hash(t1)== hash(t2)
Out[15]: True

In the same line, I think you can expect Point(1, 2) and Point(1, 2), which compare equal, also to have an equal hash.

Otherwise I think that hash based functions (eg set([..]) to get the unique elements of a sequence) will give surprising / confusing results).

Geometry objects might "inhabit" the same part of space but be different things and we'll get collisions when constructing dicts and sets if we treat spatially-coincident objects as the same object.

Can you explain a bit more the worry about collisions here?
I think the WKB of two geometries is only equal if both geometries are "really" equal (same coordinates, structural equality), and not "spatially" equal?

[mwtoews]

I think the hashing strategy needs a bit more attention. Should this be discussed as part of shapely/shapely-rfc#1 ? Or is here sufficient?

[jorisvandenbossche]

Personally, I would say this is more an API detail discussion we can have in Shapely itself (here on the PR, or in a dedicated issue for it), while the RFC discussed the general principles of mutability/hashability. But also happy to start a discussion on the RFC if others prefer that.

[mwtoews]

Superseded by #1250