``test_gdal_compliant_grid_crs`` fails with rasterio 1.4

[JoerivanEngelen]

In this giant merge of the imod5 feature branch (#1252), I updated our pixi lockfile and 2 tests failed.

One I could fix, but test_gdal_compliant_grid_crs fails with rasterio 1.4 causes a failure. For some reason:

test_gdal_compliant_grid_crs(tmpdir)
...
    da_read = rioxarray.open_rasterio(str(tmpdir / "gdal_accepted_grid.nc"))
    assert da_read.rio.crs == "EPSG:28992"
...

Gives an AssertionError, as the crs attribute equals None.

I resorted to setting rasterio to 1.3.11 in our dev environment, but it is something to keep track of.
Possibly related to:

• Test failures with rasterio 1.4 corteva/rioxarray#801
• reading a zipped raster does not return the CRS corteva/rioxarray#803

[Huite]

Might be GDAL itself:

(Rasterio) Version 1.4.0 will require GDAL >= 3.5

[JoerivanEngelen]

I think not in this case, our build already uses GDAL 3.9.3, the problem really arises when updating rasterio to 1.4.

I now locally have the test crashing in an environment with rasterio 1.4.0 and GDAL 3.9.3

With GDAL 3.9.3 and rasterio 1.3.11 everything works

[JoerivanEngelen]

Looked a bit further into this, the CRS is also not picked up by rasterio 1.4.2.

I debugged this as far as I could in the python code:
in rioxarray, there is a check: rio_crs = riods.crs or result.rio.crs,
located here

For rasterio 1.3.11, riods.crs has a value: CRS.from_epsg(28992), and result.rio.crs is None. With rasterio 1.4.2, there is no value for both.
riods is the dataset as opened by rasterio.open, unfortunately I did not manage to debug much further as I ran into Cython code from rasterio, which my Python VSCode debugger could not open.