test_fraction_on_land fails on develop in new environment

[emanuel-schmid]

The test climada.hazard.test.test_tc_surge_bathtub.TestTCSurgeBathtub.test_fraction_on_land fails since commit f0adbe7.

I assume, it is related to the updated rasterio and/or gdal versions, but I'm not 100% sure.

That the test fails is clear and the reasons are obvious. In the shore regions (fraction >0 <1) the values returned from rasterio.warp.reproject are different now. What is not clear is: are the new values any worse than the old ones? To me they look just as reasonable as the old ones, but I'm not familiar with the methods.

@tovogt: It would be great if you could have a look at this.

[tovogt]

I need more information from you: Which version of GDAL and rasterio is used in the Jenkins environment? Maybe you can directly provide me with the whole conda environment used in Jenkins. I can't reproduce this with rasterio=1.1.5 and gdal=3.0.4 on my Ubuntu 20.04 machine. Thanks in advance for your help!

[tovogt]

Okay, I was able to reproduce it now: In fact, the problem you describe is caused by a non-trivial change to the average resampling method in GDAL 3.1: OSGeo/gdal#2363 I will adapt the tests accordingly.

If you're wondering about the versions of rasterio and gdal I mentioned above: After you changed the requirements, I applied conda env update instead of creating a new environment from scratch. When creating a new environment from scratch with the new requirements files, you get different versions of rasterio and gdal. However, when using pip install -e . in the CLIMADA directory, pip downgrades the versions of rasterio and gdal to 1.1.5 and 3.0.4.

You should make sure that the version numbers in setup.py fit well with the version numbers in the requirements yml-files. However, I rather suggest to remove the version numbers from setup.py altogether. Note that, contrary to the CLIMADA docs, there seems to be a general recommendation to use pip install -e instead of conda develop: conda/conda-build#2633