Show GFW data at country level in the main dashboard

[peacog]

On the main dashboard show GFW data.

• [x] A new layer, disabled by default.
• [x] It should be clustered
• [x] Last month's data, synchronised locally (i.e. not a live query)
• [x] Text showing what date range is being displayed, in the layer name

Related to #273

[Yash621]

hey @LeScruf, just wanted to clarify some optimization points regarding this task, we have some categories here for geometries like CFR, range, sector, land etc, i was just wondering, if you might be aware of these geometries granuality which essentially means what contains what, i noticed that if i get the data just for CFR, then i cover almost all the region on the map, i just wanted to confirm if there is any region that is disjoint in nature and does not get covered if i just get the GFW data for CFR ?

[LeScruf]

Hi Yash, So if I understand what you are asking, we used to have the data arranged hierarchically (and it may still be so) - such that for the land-admin taxonomy (https://forests.stg.envs.utils.nfa.go.ug/admin/structure/asset-type) we have 9 'ranges' that cover the whole country, and each of those ranges has a sub-set of 'sectors' - each of those sectors has a sub-set of 'Beats' and then in turn each of those 'Beats' (in theory) has a subset of 'CFRs'. So whereas CFRs cover the whole country, each CFR will fall under a specific beat, sector and range, and can thus be differentiated using this hierarchy. (Note however because of data deficiencies, the beat-level is currently 'hanging'.) In addition we have semi-'standalone' geometries - which are block, compartment and zone taxonomies. Blocks, compartments and zones are used to divide / classify different parts of a CFR where such classifications have been made, and they are not part of the land admin asset type. To be clear they are non-exclusive categories. In addition where such classifications have not been made in the real world (they should have, but haven't), we also use a default 'CFR' taxonomy so that there is equivalency across the system. And finally we have 'stands' - these are stands (groups) of trees, plantation or natural forest, which are also treated as assets and which can be tracked and monitored over time. They may or may not exist for the preceding CFR, block, compartment and zone categories and they are independent of them. Does that explain things better? Let me know - I know it's rather confusing ...! Please also of course reach out to @miriam for any more developer-related questions? Cheers, Andrew

[peacog]

Thanks for the explanation @LeScruf . There's one thing I'm not clear about: "In addition where such classifications have not been made in the real world (they should have, but haven't), we also use a default 'CFR' taxonomy so that there is equivalency across the system". What asset type or field are you referring to?

Regarding this task what @Yash621 would like to know is, if he loads the GFW data for all CFRs will that include all the available data at country level? In other words, could there be GFW data for areas of the country that are not within a CFR? I'm thinking of local forest reserves and private forests (which we have made allowance for in BRMS)

[LeScruf]

Thanks for the explanation @LeScruf . There's one thing I'm not clear about: "In addition where such classifications have not been made in the real world (they should have, but haven't), we also use a default 'CFR' taxonomy so that there is equivalency across the system". What asset type or field are you referring to?

@Miriam - this one - https://forests.stg.envs.utils.nfa.go.ug/admin/structure/asset-type/cfr ? But then I've looked at the fields in this asset - and it's not what I was thinking of. The CFR asset I was thinking of is the asset that replaces blocks, compartments and zones where they don't exist in the system?

[ygoex]

Hi @Yash621, please go ahead and load the data for the CFRs. It should include all the available data.

[Yash621]

really helpful discussion guys, will update the api accordingly, thanks !

[Yash621]

hey @LeScruf just for a quick update on this, after recent testing the load times for this on main dashboard are coming to be 5mins for the first load which is getting reduced to 5-7 secs after syncing it locally, the main reason for this is on main dashboard load we are essentially fetching the data for approx 550 - 600 geometries in total, which increases the count of api calls we make from the server to 2.5k requests in one load, however with recent optimization we were able to reduce the load time from 5mins to 2.8 mins, currently we are exploring more approaches to optimize this more and reduce the load time even further, thanks !

[LeScruf]

Hi Yash, apologies for the delayed reply. Could you send me a URL? Are you referring to the national level? Let me know.

As a related but different level, on the Range GFW view the CFR polygons falling within the range are missing (e.g. https://forests.stg.envs.utils.nfa.go.ug/asset/799) and need to be displayed to provide the requisite context? Can this be added to the layer? We can spin this out to a new(!) issue if needed.

[peacog]

@LeScruf the GFW map for the main dashboard hasn't been deployed to staging yet because we doubted whether the 3 minute loading time would be acceptable. If you'd like to see it we can deploy it.

As for the CFR polygons, we have another issue to deal with that one, no #288

[LeScruf]

Hi @Yash621 and @peacog - makes sense. I agree. I think if it's looking a stretch, let's leave it and focus our energies on other things? Speaking of which @peacog - I am meeting with Edward later this afternoon to finalise and hopefully send over your first set of polygon folders. Let's see.

[peacog]

@Yash621 I made some changes to the GFW js in #289 and the data is now loading a lot quicker than it used to. Can you take a look at this task again to see if those changes help with the data loading performance we're trying to solve in this ticket?