Closed gdaldegan closed 1 year ago
Can you tell me more what scenario we'd need this for @gdaldegan? My thought would be that if you have two different legends, then you shouldn't be calculating change among the two layers - I'm not sure how you'd know whether any "change" is due to actual change on the land, a change in class name between the two legends, or a change in class definition between the two legends.
I'm trying to run Land Cover Change sub-indicator using imported custom LC layers for a small subset of the Colombian Amazon region. Importing LC 2000, the original data doesn't have the class 13
Class 13 is a non-forest natural vegetation, which in my interpretation likely represents forest pixels that were cleared at some point early to mid the 15y time-series and than abandoned, so began a natural regeneration succession - LC Legend:
This scenario is very likely to happen in recently occupied natural landscapes.
When importing LC 2015, which now does have class 13, I match it to Grassland for a lack of another standard class.
Then trying to run LC Change, I get that message
Thus I don't fully understand the rule, given I'm matching the original classes to the 7 standard UNCCD classes:
Ah, ok. I see what you mean. Can you try saving the full legend from the 2015 data to a file, and then loading it from file when importing the 2000 data? This should then add that class to the legend even though it isn't in the file.
Also once #626 is merged, the best way to do this would be to first set a custom legend, and then import the land cover data. This would allow matching that legend directly and avoid the issue of different legends across years.
No longer an issue with new LC tool
I don't think Trends.Earth should have the rule below, given it is quite common to have distinct land cover classes between the initial and final layers.