Link LAI and landuse classes

hboisgon commented 3 months ago

Issue addressed

Fixes #243

Explanation

See issue.

For deriving LAI values, I used several methods:

any: if any cell of the landuse class is in the larger LAI cell, it will be used. -> every landuse class will get a value at high resolution
mode: only if the landuse class after mode is reprojected to LAI, it will be used. -> not every landuse class may get a value at high resolution but they will at the wflow resolution.
q3: only if mode and 75% of the larger LAI cell is covered by that landuse class, it will be used. -> not every landuse class may get a value at high and wflow resolution.

TODO

[x] If this should be part of the next release then update the changelog, else wait for after the release to avoid conflict.
[x] Optional: try and see if we can prepare pre-defined tables. I started looking at deriving tables per merit hydro pfaf2 basins (60 basins). These will be added to the deltares p drive for testing including a separate data catalog.

Checklist

[x] Updated tests or added new tests
[x] Branch is up to date with main
[x] Tests & pre-commit hooks pass
[x] Updated documentation if needed

Additional Notes (optional)

hboisgon commented 3 months ago

@JoostBuitink do you have any preference for the last items in the TODO list?

shartgring commented 2 months ago

Hi Hélène! I was taking a look at the naming of the functions in the workflows. Now there is a lulc_lai_mapping and a lai_from_lulc_mapping. I got them a bit confused during the review, and thought of renaming lulc_lai_mapping to lulc_to_lai_mapping. However, I am not sure if that would be an improvement after some thought. Or rename lulc_lai_mapping to create_lulc_lai_mapping_table? What do you think?

shartgring commented 2 months ago

I was also wondering. Did you perhaps do a check with such a table where you generated LULC and LAI maps, created a mapping table (with different resampling methods) to create new LAI maps? And compare those to the original LAI maps to see how they perform? I think that this would be a nice check.

I could also do this myself for some models but that may take some time and delay the implementation of this PR due to my travels next week ;)

hboisgon commented 2 months ago

Hi Hélène! I was taking a look at the naming of the functions in the workflows. Now there is a lulc_lai_mapping and a lai_from_lulc_mapping. I got them a bit confused during the review, and thought of renaming lulc_lai_mapping to lulc_to_lai_mapping. However, I am not sure if that would be an improvement after some thought. Or rename lulc_lai_mapping to create_lulc_lai_mapping_table? What do you think?

I agree, it's a good suggestion. It's workflows name so they are not used often by users but create_lulc_lai_mapping_table sounds clearer

hboisgon commented 2 months ago

I was also wondering. Did you perhaps do a check with such a table where you generated LULC and LAI maps, created a mapping table (with different resampling methods) to create new LAI maps? And compare those to the original LAI maps to see how they perform? I think that this would be a nice check.

I could also do this myself for some models but that may take some time and delay the implementation of this PR due to my travels next week ;)

I do test creating for piave with lai from modis and the mapped lai. From the tests, you can already see that depending on the sampling method, you get quite different values in the mapping table. I dont think we really need to test for this PR, also not sure how sensitive wflow models are to LAI and if the small differences with modis or the mapping table will impact the model much. I think this will something for users/projects to figure out and get experience with

Deltares / hydromt_wflow