and just to confirm that this does seem to be much faster in the worst cases than it was before. Not as fast as directly comparing the wkt properties or the cached EPSG code, but I'd call a drop from the worst case of 20 ms to 5 us pretty good.

If one wanted to be even more pedantic, I think you would call the current equality method an "nearly equal" due to the allowable changes in the coordinate axes and one would reserve the equality test to the more strict wkt comparison.

In [25]: e = rio.CRS.from_epsg(4326)

In [26]: m = rio.CRS.from_user_input('IAU_2015:49900')

In [27]: e == m
Out[27]: False

In [28]: %timeit e.wkt == e.wkt
42.1 ns ± 0.0115 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)

In [29]: %timeit e == e
5.14 μs ± 5.81 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)

In [30]: %timeit m == m
5.03 μs ± 2.46 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)

In [31]: m2 = rio.CRS.from_wkt('GEOGCS["Mars (2015) - Sphere XY",DATUM["Mars (2015) - Sphere",SPHEROID["Mars (2015) -
    ...:  Sphere",3396190,0]],PRIMEM["Reference Meridian",0],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"
    ...: ]],AXIS["Longitude",EAST],AXIS["Latitude",NORTH]]')

In [32]: m2 == m
Out[32]: True

In [33]: %timeit m == m2
10.2 μs ± 6.3 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)

new equals method with default ignore_axis_order=false while now ensuring CRS.from_epsg(4326) != CRS.from_string("OGC:CRS84") made it necessary to update two equality assertions between two tests

@sgillies in which version should we release this? do we have to wait for 1.5 or it could go into 1.4.2?

@AndrewAnnex Could you add a note in the changelog 🙏

@vincentsarago there's a new method. Strictly speaking we can't add new methods in 1.4.2 if we're doing semantic versioning. I'm working on a backport for 1.4.2 that improves performance only.

@sgillies I can also break the pr apart if needed to separate the new .equals function. Or if you can add me as a co-author to the commit that's fine too

@vincentsarago still need me to add the change log entry for 1.5.0 or wait for the backport first? It doesn't look like rasterio follows the convention of including un-released versions with TBD dates in CHANGES.txt, so otherwise I'd have to add a line for 1.5.0 and 1.4.2... happy to do both/one/the other

@AndrewAnnex I'm going to merge this. The "backport" is a little more extensive than this PR as it eliminates more to_epsg() usage in the package and removes a bunch of test assertions about old PROJ4 "+init=x" usage.

Don't worry about the change log. I'll take care of that when I merge 1.4.2 to main.