Naming of crops

[FraGard]

@YSaedi, we're updating a CLEWs model of Sri Lanka using this workflow for the crop data. From FAOSTAT, the 10 main crops are:
Rice; Coconuts, in shell; Tea leaves; Natural rubber in primary forms; Other fibre crops, raw, n.e.c.; Maize (Corn); Plantains and cooking bananas; Pepper (Pipper spp.), raw; Cinnamon and cinnamon-free flowers, raw; Mangoes, guavas and mangosteens
In the Crop_code.csv, in the 'Name' column, some of those (among the above) that are available are named differently. Because of the exact matching condition in block 2.1.2, they do not get picked up for further analysis. Is there some way around this? I suppose a 'contains' condition is hard, because that wouldn't work with crops like rice (there's both dryland and wetland). Maybe then we need to review the Name column to match exactly all categories from FAOSTAT?

[YSaedi]

@FraGard, It's an area that requires improvement, and this extends to other aspects such as the CLEWs code for crops as well. There are discrepancies among the available CLEWs codes, FAOSTAT crop categories, and GAEZ crop classifications.
For instance, there are five different GAEZ categories for Maize, which don't align perfectly with FAOSTAT and CLEWs code. This can lead users to miss out on processing the most appropriate raster file. However, if GeoCLEWs retrieves all five different Maize categories, it will significantly increase processing time and add unnecessary complexity to the modelling. There are similar examples, like Rice, where the "Rice" class in the "Name" column is split into "Dryland rice" and "Wetland rice," which might not match exactly. This points to the need for users to decide which data is the most suitable for their needs as there are separate categories for dryland and wetland in both the CLEWs code and the GAEZ database. While it might not be the most optimal solution, it helps avoid collecting unrelated GAEZ datasets and reduces computational complexity.

[tniet]

This is definitely an issue! Just ran across this as well. My suggestion is to implement error codes in the script. Tagging @junohBede as I think this is something he can do.