Link LAI and landuse classes

[hboisgon]

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

• If this should be part of the next release then update the changelog, else wait for after the release to avoid conflict.
• 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

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

Additional Notes (optional)

[hboisgon]

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

[shartgring]

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]

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]

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]

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

[shartgring]

Finished the review, looks good! I already saw your replies to my comments and I agree. So I suggest some minor changes for readability of the code and documentation and then it is good to go

[shartgring]

The option is mentioned here to use the landuse map of the Wflow model. This option does not appear in setup_lai_from_lulc_mapping, at least not explicitly (one could load the landuse map as a DataArray and pass it to the method). Is that something to add as a functionality to the method? Or remove the remark here if it is not implemented?

[shartgring]

If someone derives the landuse maps for wflow, he/she will likely use setup_lulc to generate the map. And in that case, it would make more sense to use the original lulc data than using the staticmap itself. Or am I maybe missing a specific use case?

[hboisgon]

Good question! Well you can always add the wflow staticmaps to your data catalog and I can imagine when you create a landuse scenario (eg crops into forest), you can update the original landuse map or decide to copy and update the wflow landuse map. I think it's always better to modify the original data but you never know.

[shartgring]

Here we allow the user to specify a resampling method but in the landuse workflow the methods are fixed by a global variable RESAMPLING. I was wondering, would it be nice to include the option for resampling methods in the land use workflow for the user, similar to this? (Not as part of this PR) Or is there a good reason that it is fixed for that workflowbut not in this one?

[hboisgon]

Yes this not the resampling method of the landuse map but more how to sample lai values for each landuse class. Modis is lower resolution so you may have several landuse classes in one MODIS/LAI values. So you can decide to use that LAI values if only all LU cells are the same class, the majority or any. I can maybe rename to sampling method to make it clearer.

[shartgring]

Check, clear!