Make use of the Argentina goverment forest loss data that I rasterized in arg_otbn_forest_loss in the forest_change_diagnostic analysis.
We are putting the forest loss from Argentina and Brazil (prodes) in new country-specific forest loss columns, so we don't have new columns for every new country with government data. However, for ease of transition, I have been requested to leave in the prodes columns. We will remove the prodes columns another change soon after the GFWPro front-end is using the country-specific columns for Argentina and Brazil.
The Argentina data adds an extra wrinkle, in that much of the forest loss is attributed to a range of years (such as 2013-2017) rather than an exact year. We represent such forest loss as occurring in 2017, but with an extra "approximate" flag that indicates the forest loss occurred in a multi-year range ending in that year. In the Geotrellis code, I added a new ApproxYear datatype, and also a new ForestChangeDiagnosticDataLossApproxYearly which gathers forest loss than can include approximate years.
There are three new country-specific forest loss columns (the basic data, plus intersection with WDPA and primary_forest). Also, there is a country code column that indicates which country the country-specific forest loss is from (currently just Argentina and Brazil).
We don't want to mix country-specific forest loss for two countries. In the unusual case where location spans two countries and has forest loss in both countries, we convert the country code to "ERR" and zero out the country-specific forest loss. I don't ever expect this case to happen in practice, but we want to see if there are any such locations in the GFWPro database.
Other misc. changes:
I made constants TreeCoverLossYearStart and TreeCoverLossYearEnd in ForestChangeDiagnosticCommand. This makes our current TCL forest loss year (2022) appear in just one place. Fixed the various prefilled functions to use TreeCoverLossYearStart and TreeCoverLossYearEnd, so we don't need modify each one separately.
corrected a few spelling mistakes in variable names.
danscales
commented
9 months ago
Make use of the Argentina goverment forest loss data that I rasterized in arg_otbn_forest_loss in the forest_change_diagnostic analysis.
We are putting the forest loss from Argentina and Brazil (prodes) in new country-specific forest loss columns, so we don't have new columns for every new country with government data. However, for ease of transition, I have been requested to leave in the prodes columns. We will remove the prodes columns another change soon after the GFWPro front-end is using the country-specific columns for Argentina and Brazil.
The Argentina data adds an extra wrinkle, in that much of the forest loss is attributed to a range of years (such as 2013-2017) rather than an exact year. We represent such forest loss as occurring in 2017, but with an extra "approximate" flag that indicates the forest loss occurred in a multi-year range ending in that year. In the Geotrellis code, I added a new
ApproxYeardatatype, and also a newForestChangeDiagnosticDataLossApproxYearlywhich gathers forest loss than can include approximate years.There are three new country-specific forest loss columns (the basic data, plus intersection with WDPA and primary_forest). Also, there is a country code column that indicates which country the country-specific forest loss is from (currently just Argentina and Brazil).
We don't want to mix country-specific forest loss for two countries. In the unusual case where location spans two countries and has forest loss in both countries, we convert the country code to "ERR" and zero out the country-specific forest loss. I don't ever expect this case to happen in practice, but we want to see if there are any such locations in the GFWPro database.
Other misc. changes:
I made constants
TreeCoverLossYearStartandTreeCoverLossYearEndinForestChangeDiagnosticCommand. This makes our current TCL forest loss year (2022) appear in just one place. Fixed the variousprefilledfunctions to useTreeCoverLossYearStartandTreeCoverLossYearEnd, so we don't need modify each one separately.corrected a few spelling mistakes in variable names.