Hash/Equality contract violation

[T90REAL]

Code Sample, a copy-pastable example if possible

from pyproj import CRS

a = CRS.from_epsg(3857)
b = CRS.from_wkt(a.to_wkt())

print(a == b)          # True
print(hash(a), hash(b))  # hashes differ

Problem description

Two CRS instances that compare equal (a == b) produce different hash values after a round-trip through WKT. Because CRS.__hash__ delegates to self.to_wkt(), and to_wkt() can emit different—but equivalent—representations, the Python hash/equality contract is violated. This breaks dictionaries, sets, and caches keyed by CRS, since lookups may fail or duplicates may be stored.

Expected Output

Objects that compare equal should yield identical hashes. The code sample above should print True twice.

Environment Information

• Output from: pyproj -v

 pyproj info:
     pyproj: 3.7.2
 PROJ (runtime): 9.5.1
 PROJ (compiled): 9.5.1
   data dir: /home/hdd/PBT-AgentSys/src/envs/pyproj_env/lib/python3.12/site-packages/pyproj/proj_dir/share/proj
 user_data_dir: /home/.local/share/proj
 PROJ DATA (recommended version): 1.20
 PROJ Database: 1.4
 EPSG Database: v11.022 [2024-11-05]
 ESRI Database: ArcGIS Pro 3.4 [2024-11-04]
 IGNF Database: 3.1.0 [2019-05-24]

 System:
     python: 3.12.12 | packaged by Anaconda, Inc. | (main, Oct 21 2025, 20:16:04) [GCC 11.2.0]
 executable: /home/hdd/PBT-AgentSys/src/envs/pyproj_env/bin/python3
    machine: Linux-5.15.0-139-generic-x86_64-with-glibc2.31

 Python deps:
    certifi: 2025.10.5
     Cython: None
 setuptools: None
        pip: 25.0.1

Installation method

pip (inside a virtual environment)

[djhoese]

I wonder if this could be considered a "bug" in the to_wkt method and therefore in the PROJ library. I'm also curious how many CRSes run into this inequality (all, EPSG-based? EPSG with a specific projection/datum/etc)? I wonder if this is an argument for swapping what type of equality __eq__ uses (exact/strict versus "equivalent"):

pyproj/pyproj/_crs.pyx

Lines 485 to 502 in bc88b98

	def _is_exact_same(self, Base other):
	return proj_is_equivalent_to_with_ctx(
	self.context, self.projobj, other.projobj, PJ_COMP_STRICT) == 1
	def _is_equivalent(self, Base other):
	return proj_is_equivalent_to_with_ctx(
	self.context, self.projobj, other.projobj, PJ_COMP_EQUIVALENT) == 1
	def __eq__(self, other):
	if not isinstance(other, Base):
	return False
	return self._is_equivalent(other)
	def is_exact_same(self, other):
	"""Compares projection objects to see if they are exactly the same."""
	if not isinstance(other, Base):
	return False
	return self._is_exact_same(other)

[T90REAL]

Thanks for the response. I agree to_wkt() producing different strings isn’t itself a bug—PROJ adds metadata, so equivalent CRSes often serialize differently. The problem is that CRS.__eq__ deliberately uses the “equivalent” test, but CRS.__hash__ hashes the raw WKT string. Switching __eq__ to strict would break that established behavior. A smaller fix probably is to hash a normalized representation aligned with the existing equality semantics.

[snowman2]

A smaller fix probably is to hash a normalized representation aligned with the existing equality semantics.

WKT is the best nornalized representation that I am aware of.

[djhoese]

@T90REAL do you have an example of the extra metadata that PROJ is adding that is making the WKT not equal?

[T90REAL]

@T90REAL do you have an example of the extra metadata that PROJ is adding that is making the WKT not equal?

Sure. Using the following command:

>>> from pyproj import CRS
>>> a = CRS.from_epsg(3857)
>>> b = CRS.from_wkt(a.to_wkt())
>>> print(a.to_wkt(pretty=True))
PROJCRS["WGS 84 / Pseudo-Mercator",
    BASEGEOGCRS["WGS 84",
        ENSEMBLE["World Geodetic System 1984 ensemble",
            MEMBER["World Geodetic System 1984 (Transit)"],
            MEMBER["World Geodetic System 1984 (G730)"],
            MEMBER["World Geodetic System 1984 (G873)"],
            MEMBER["World Geodetic System 1984 (G1150)"],
            MEMBER["World Geodetic System 1984 (G1674)"],
            MEMBER["World Geodetic System 1984 (G1762)"],
            MEMBER["World Geodetic System 1984 (G2139)"],
            MEMBER["World Geodetic System 1984 (G2296)"],
            ELLIPSOID["WGS 84",6378137,298.257223563,
                LENGTHUNIT["metre",1]],
            ENSEMBLEACCURACY[2.0]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433]],
        ID["EPSG",4326]],
    CONVERSION["Popular Visualisation Pseudo-Mercator",
        METHOD["Popular Visualisation Pseudo Mercator",
            ID["EPSG",1024]],
        PARAMETER["Latitude of natural origin",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        PARAMETER["Longitude of natural origin",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["False easting",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["easting (X)",east,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["northing (Y)",north,
            ORDER[2],
            LENGTHUNIT["metre",1]],
    USAGE[
        SCOPE["Web mapping and visualisation."],
        AREA["World between 85.06°S and 85.06°N."],
        BBOX[-85.06,-180,85.06,180]],
    ID["EPSG",3857]]
>>> 
>>> print(b.to_wkt(pretty=True))
PROJCRS["WGS 84 / Pseudo-Mercator",
    BASEGEOGCRS["WGS 84",
        DATUM["World Geodetic System 1984",
            ELLIPSOID["WGS 84",6378137,298.257223563,
                LENGTHUNIT["metre",1]]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433]],
        ID["EPSG",4326]],
    CONVERSION["unnamed",
        METHOD["Popular Visualisation Pseudo Mercator",
            ID["EPSG",1024]],
        PARAMETER["Latitude of natural origin",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        PARAMETER["Longitude of natural origin",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["False easting",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["easting (X)",east,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["northing (Y)",north,
            ORDER[2],
            LENGTHUNIT["metre",1]],
    USAGE[
        SCOPE["Web mapping and visualisation."],
        AREA["World between 85.06°S and 85.06°N."],
        BBOX[-85.06,-180,85.06,180]],
    ID["EPSG",3857]]

[snowman2]

That looks like PROJ is losing information when reading the WKT. I think that is a PROJ bug.

[djhoese]

Yeah, agreed. Seems like some "simplification" of the ENSEMBLE datum. @T90REAL would you mind filing a bug with PROJ? I'm not sure how easy it would be to reproduce this with just the command line tools in PROJ though. It may require actual C++ code.

[djhoese]

I filed an issue with PROJ after this came up again for my own project: OSGeo/PROJ#4842

[djhoese]

PROJ 9.9.0RC1 has the fix for this. It'll need to be tested. If I'm reading the patch correctly it handles the unnamed/unknown differences but does not provide a new higher-level "hashable version of a CRS".