test failure looks unrelated to changes made in this PR and occur in tests/test_warpedvrt.py

would be great to merge this after #3206 (but not before #3227, this pr can wait for a future version)

I am a little late to the party here, but figured this insight may be helpful when deciding on naming in to_geodetic versus geodetic_crs.

geodetic_crs is a property of the CRS. An example is seen here:
https://pyproj4.github.io/pyproj/stable/build_crs.html#projected-crs

from pyproj.crs import GeographicCRS, ProjectedCRS
from pyproj.crs.coordinate_operation import UTMConversion
from pyproj.crs.datum import CustomDatum, CustomEllipsoid

ell = CustomEllipsoid(semi_major_axis=6378137, semi_minor_axis=6356752)
cd = CustomDatum(ellipsoid=ell, prime_meridian="Lisbon")
proj_crs = ProjectedCRS(
    conversion=UTMConversion(14), geodetic_crs=GeographicCRS(datum=cd)
)

In this example, calling geodetic_crs, you are retrieving the geodetic CRS of the original CRS and not converting it to a geodetic CRS.

Also, pyproj caches the internal _geodetic_crs code to improve the performance in the scenario that it is called multiple times.

@snowman2 That makes sense regarding the naming. I wanted to keep the scope of this PR limited to make it easier to merge, but we could update the pr to go the route of Pyproj to make the api more equivalent. But it would require the similar caching mechanism. But it is unclear given the prior approval from @sgillies if that's the desired outcome for this PR.

The information above was for informational purposes for decision making and design considerations only. Caching is not a requirement, just sharing so you are aware.

@snowman2 that appeals to me, and it's good to have Rasterio and Pyproj agree, even though I think Rasterio can be less complete than Pyproj (there's a lot of other stuff to be concerned about). For example, Rasterio doesn't need (as far as I can tell) to be able to create generic projected CRS, passing a geodetic CRS to the constructor. Rasterio really only needs to work with standardized CRS. Engineering CRS might be an exception to this.

@AndrewAnnex are you okay with making this an attribute instead of a method?

@sgillies yep I am happy to implement that, I'll get to it later today or tomorrow

okay I think this does what's needed but happy to respond to feedback. I'd also wonder if there is a good example projected CRS that doesn't have a resolvable geodetic CRS to test that case but that might require making a projection with a custom geographic crs that doesn't compare to anything... something I'll think more about

I'd also wonder if there is a good example projected CRS that doesn't have a resolvable geodetic CRS...

@AndrewAnnex this is an interesting question. Let me know what you discover.

I forgot to ask "what is the geodetic CRS corresponding to a geodetic CRS?" but it seems that GDAL and PROJ do the least surprising thing 👍

>>> from rasterio.crs import CRS
>>> CRS.from_epsg(32618).geodetic_crs
CRS.from_wkt('GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AXIS["Latitude",NORTH],AXIS["Longitude",EAST],AUTHORITY["EPSG","4326"]]')
>>> CRS.from_epsg(32618).geodetic_crs.geodetic_crs
CRS.from_wkt('GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AXIS["Latitude",NORTH],AXIS["Longitude",EAST],AUTHORITY["EPSG","4326"]]')