Plotting hazards with inapt crs

[emanuel-schmid]

Starting from climada 5.0, the crs of a Centroids object is bound to its GeoDataFrame (centroids.gdf).

It is possible though to create a Centroids object with an inapt crs by using Centroids.from_meta and a crs like, e.g.:

<Engineering CRS: LOCAL_CS["unnamed",UNIT["unknown",1],AXIS["Easting ...>
 Name: unnamed
 Axis Info [cartesian]:
 - [east]: Easting (unknown)
 - [north]: Northing (unknown)
 Area of Use:
 - undefined
 Datum: undefined
 - Ellipsoid: undefined
 - Prime Meridian: undefined)

This can happen if the hazard object is read from a shp file. (e.g., climada_petals.hazard.landslide.Landslide.from_prob).

Any hazard object based on this will behave normally, in general, but plotting (plot_intensity) raises an error as well as to_crs. The only remedy to fix the crs is by directly overwriting it:

haz.centroids.gdf.crs = apt_crs

I think we should possibly fix this in from_meta, but at least allow replacing a broken crs with a good one in to_crs.

[chahank]

hmmm, is the crs not written into the centroids when using the Hazard.from_raster method (if not explicitly given, it uses the default one)?

[emanuel-schmid]

Why? Yes. I suppose the problem arises just because the crs is explicitly given but not suitable for plotting (or other meaningful crs handling).

[chahank]

Aaa sorry, I get it know. It is that the crs is not readable by cartopy.

But then the fix should be in setting the correct crs when reading the data no?

[emanuel-schmid]

I agree.

However:

• it is obviously possible to mess up and assign a faulty crs to a GeoDataFrame
• the GeoDataFrame cannot be set fixed by to_crs, but only by direct assignment

Therefore I think that our (the Centroids') to_crs should actually catch that error and fix it, because we don't want anybody to have to touch the gdf.

[chahank]

aaa good point!