upgrade_shapely_2.0_fix by emanuel-schmid · Pull Request #731 · CLIMADA-project/climada_python
I think that there is a more fundamental issue here.
The read_raster function takes an argument geometry that is passed on to rasterio.mask.mask as the shapes argument. The docstring of read_raster specifies the type of the geometry to be a shapely.geometry, but the docstring of rasterio.mask.mask specifies the type of shapes to be an iterable of geometries.
This was never correct, even before the 2.0 upgrade for shapely.
The tests for read_raster are currently passing a list of geometries so that the tests don't fail even though the tests aren't according to the docstring:
| meta, inten_ras = u_coord.read_raster(HAZ_DEMO_FL, geometry=[poly]) |
I suggest to rename the kwarg to geometries and correctly specify its type as list of shapely.geometries in the docstring. Then go through the core and petals code base and replace the calls to read_raster accordingly. There are only a few places that are affected by this. Furthermore, I don't think that we need to have backwards compatibility here, because my impression is that the read_raster function is so overwhelming that almost nobody uses it outside of the CLIMADA code.
Note that this issue also affects the Exposures.from_raster functionality since the arguments are basically passed on to the read_raster function:
| def from_raster(cls, file_name, band=1, src_crs=None, window=False, | |
| geometry=False, dst_crs=False, transform=None, | |
| width=None, height=None, resampling=Resampling.nearest): | |
| """Read raster data and set latitude, longitude, value and meta | |
| Parameters | |
| ---------- | |
| file_name : str | |
| file name containing values | |
| band : int, optional | |
| bands to read (starting at 1) | |
| src_crs : crs, optional | |
| source CRS. Provide it if error without it. | |
| window : rasterio.windows.Windows, optional | |
| window where data is | |
| extracted | |
| geometry : shapely.geometry, optional | |
| consider pixels only in shape |
geometry argument in the Exposures.from_raster function, and propose to change this argument to geometries, as well.