Work towards #53: To optionally fetch Integrated Deforestation Alerts from the GFW API and add those to the Alerts Dashboard.
Discussion
The objective of this PR is not to submit code for review and merging. Instead, it should serve as a vehicle for discussion toward a better approach, as the method used here is definitely inefficient.
The GFW API yields vector data by doing raster analysis on the fly, resulting in a high amount of latency, and there is a payload ceiling of 5,291,556 bytes. Using the method implemented here, even an API query for a relatively small AOI around the village of Kawemhakan in Suriname took 875.657ms (for 668 points). For the entire Wayana territory, we reached the payload ceiling.
It seems to me that there are two options to overcome this:
(1) I think this approach to fetch data from the GFW API could work if we are actually storing the response in a database or as a GeoJSON file, which we update regularly with new GFW data. We could easily write a frizzle pull component to do this. This would be the way to go if we want to serve GFW data as alerts: that is, as active features on the Alerts Dashboard that you can click on to view properties, and export as CSV/GeoJSON. Not to mention that we will eventually make it possible for users to add data to alerts, and relate together alerts that belong to the same incident.
(2) If we just want to visualize GFW data on an alerts dashboard as a contextual map layer and nothing more, then we should see if GFW makes a public tileset of their data available somewhere. We wouldn't need to worry about limiting it to an AOI since tiled data is only loaded for your viewport anyway.
I think that if we want to provide GFW data as an open alternative to proprietary change detection data, then we should consider (1).
Screenshots
What I changed
For the /alerts API, optionally fetch gfw_integrated_alerts data from the GFW API, and return that as a GeoJSON object, to be added as a source and layer on the AlertsDashboard map canvas.
Goal
Work towards #53: To optionally fetch Integrated Deforestation Alerts from the GFW API and add those to the Alerts Dashboard.
Discussion
The objective of this PR is not to submit code for review and merging. Instead, it should serve as a vehicle for discussion toward a better approach, as the method used here is definitely inefficient.
The GFW API yields vector data by doing raster analysis on the fly, resulting in a high amount of latency, and there is a payload ceiling of 5,291,556 bytes. Using the method implemented here, even an API query for a relatively small AOI around the village of Kawemhakan in Suriname took 875.657ms (for 668 points). For the entire Wayana territory, we reached the payload ceiling.
It seems to me that there are two options to overcome this:
(1) I think this approach to fetch data from the GFW API could work if we are actually storing the response in a database or as a GeoJSON file, which we update regularly with new GFW data. We could easily write a frizzle pull component to do this. This would be the way to go if we want to serve GFW data as alerts: that is, as active features on the Alerts Dashboard that you can click on to view properties, and export as CSV/GeoJSON. Not to mention that we will eventually make it possible for users to add data to alerts, and relate together alerts that belong to the same incident.
(2) If we just want to visualize GFW data on an alerts dashboard as a contextual map layer and nothing more, then we should see if GFW makes a public tileset of their data available somewhere. We wouldn't need to worry about limiting it to an AOI since tiled data is only loaded for your viewport anyway.
I think that if we want to provide GFW data as an open alternative to proprietary change detection data, then we should consider (1).
Screenshots
What I changed
/alertsAPI, optionally fetchgfw_integrated_alertsdata from the GFW API, and return that as a GeoJSON object, to be added as a source and layer on theAlertsDashboardmap canvas.