Use pyproj.CRS internally

[snowman2]

In geopandas 7+ they are now using the pyproj.CRS class (https://geopandas.readthedocs.io/en/latest/projections.html). This can potentially be problematic if the user has GDAL 2 installed with pyproj wheels in this example: https://corteva.github.io/rioxarray/stable/examples/clip_geom.html

It will likely also cause issues with: https://github.com/corteva/geocube

Currently when passing in WKT2 or a pyproj.CRS or a proj string/dict with type=crs in it and you have GDAL 2 installed, rasterio will raise an error. However, this is not an issue with pyproj.CRS. It can accept anything. It just cannot be accepted by everything until GDAL 3 becomes more widely used.

So, I am thinking about using the pyproj.CRS to bridge the divide internally. The rasterio..crs.CRS will still be exposed to users since this is rioxarray and it can be accepted by pyproj.CRS just fine.

The internal logic would look like:

from pyproj import CRS
crs = CRS.from_user_input(crs_input)
if gdal_version < 3:
    wkt = crs.to_wkt("WKT1_GDAL")
else:
    wkt = crs.to_wkt()

[snowman2]

This looks like a good spot for the logic:

rioxarray/rioxarray/crs.py

Lines 7 to 25 in 5a26444

	def crs_to_wkt(rasterio_crs):
	"""
	This is to deal with change in rasterio.crs.CRS.
	Parameters
	----------
	rasterio_crs: :obj:`rasterio.crs.CRS`
	Rasterio object.
	Returns
	-------
	str: WKT string.
	"""
	try:
	# rasterio>=1.0.14
	return rasterio_crs.to_wkt()
	except AttributeError:
	return rasterio_crs.wkt

[snowman2]

Seems like it is duplicated here - must have missed it:
https://github.com/corteva/geocube/blob/master/geocube/geo_utils/crs.py

[djhoese]

I like the idea of this and this is what I was hoping to do with geoxarray. This may make geoxarray completely unnecessary, but that is probably a good thing. My goal is still to make geoxarray without the dependency on rasterio/GDAL. If cartopy could use pyproj CRS objects then 💥 the entire ecosystem would be changed.

[snowman2]

My goal is still to make geoxarray without the dependency on rasterio/GDAL

I still think that is a useful goal to have. For starters, it could manage the CF convention based CRS read/write using pyproj.CRS.

f cartopy could use pyproj CRS objects then boom the entire ecosystem would be changed.

That would be nice - a world where the CRS classes in the python geospatial ecosystem just work together :). (ref: SciTools/cartopy#1477)