0

I check crs congruency as means of quality control prior to spatial analysis involving a geodataframe (gdf) and a raster (rstr).

print(gdf.crs)

returns 'epsg:2193'

and

print(rstr.crs)

returns 'EPSG:2193'

which is notionally OK as cross-checking in QGIS confirms they're the same. However, a logical test:

gdf.crs == rstr.crs

returns 'False'

While this appears like it could be a simple matter of case-sensitivity, I noticed they are two different data types (<class 'pyproj.crs.crs.CRS'> and <class 'rasterio.crs.CRS'>, respectively) so maybe that's the inequality?

What's my best option for resolving how the two different packages return crs?

CreekGeek
  • 1,809
  • 2
  • 14
  • 24

1 Answers1

2

CRS can be stored in many ways. For example PROJ, EPSG-Code or WKT-format (Well known text), which preferred as a lossless way of storing CRS information. For reference, check the PROJ explanation of the best format for describing coordinate reference systems here.

In your case geopandas returns the PROJ (here Python implementation PyProj), which is one of the more prominent ones. Interestingly Rasterio has it's own way of storing CRS information, the class 'rasterio.crs.CRS'. Comparing two different implementations of storing CRS should be 'False'. To resolve this you need to define the storing format as well.

Comparing the EPSG-Codes as strings (and not the underlying CRS-storing classes) should be enough for your task.

Rasterio has a function to return the EPSG-code:

rstr.to_epsg()

geopandas provides similar functionalities (scroll down a bit):

gdf.crs.to_epsg()
Magnus
  • 305
  • 3
  • 12
  • Interesting diversity in how it gets handled. Cheers for the insight. rstr.to_epsg() doesn't work for me, but even better (simpler) that *.crs.to_epsg() does work for both objects. You totally got me on the right track so marking as answered. – CreekGeek Jun 28 '21 at 20:23