This PR adds a comprehensive workflow to add Mapeo data to the alerts API and dashboard, and have all of the same behaviors as alerts (e.g. select a feature, change the color when selected, view in sidebar, download CSV/GeoJSON).
The app now takes two new env vars (MAPEO_TABLE and MAPEO_CATEGORY_IDS) for an alerts view in NUXT_ENV_VIEWS_CONFIG.
If set, the /alerts API will pull data from the MAPEO_TABLE var and filter only the MAPEO_CATEGORY_IDS - the idea here is that only specific categoryIds (e.g. those related to threats) from a Mapeo dataset should be shown on the map.
AlertsDashboard receives this data from the API response as a prop, and using a new function addMapeoData, adds it to the map.
For clarity, addDataToMap and data were renamed to addAlertsData and alertsData, respectively.
For mouseovers, I noticed that hovering from one feature to another was resetting the cursor, so I added a featuresUnderCursor helper variable to store the number of features under the cursor. Now, the cursor only resets when that var is equal to 0, resolving the issue.
Introduce isAlert variable based on "Alert ID" field to differentiate alerts from Mapeo data, and use that to conditionally show/hide Media for each.
Some small changes to components like Download, Feature, Map, mapFunctions (related to Legend) to get Mapeo data to work for the respective tasks in each component and/or look nicer.
In Features, conditionally render a field data_source as a header. (For now, I just assume that it exists in the database table; would like to think through if this possible to introduce in frizzle.)
I introduced some timestamp rewrites in transformData to render the created and modified fields as legible dates in the sidebar.
In mapFunctions, I introduced new function prepareCoordinatesForSelectedFeature to rewrite a Mapeo [long,lat] coordinate to show as lat, long in the sidebar instead (e.g. for usage in Google Maps).
The default point color was changed to blue to disambiguate them from orange alerts.
What I'm not doing here
Identifying Mapeo vs. Alert data deterministically, which ideally should come from the database (e.g. maybe frizzle). Will file an issue for this later.
Allowing the Mapeo data color to be set (I want to consider the best approach for this in later work).
Closes https://github.com/ConservationMetrics/guardianconnector-views/issues/47.
Goal
This PR adds a comprehensive workflow to add Mapeo data to the alerts API and dashboard, and have all of the same behaviors as alerts (e.g. select a feature, change the color when selected, view in sidebar, download CSV/GeoJSON).
Screenshots
What I changed
MAPEO_TABLEandMAPEO_CATEGORY_IDS) for an alerts view inNUXT_ENV_VIEWS_CONFIG./alertsAPI will pull data from theMAPEO_TABLEvar and filter only theMAPEO_CATEGORY_IDS- the idea here is that only specific categoryIds (e.g. those related to threats) from a Mapeo dataset should be shown on the map.AlertsDashboardreceives this data from the API response as a prop, and using a new functionaddMapeoData, adds it to the map.addDataToMapanddatawere renamed toaddAlertsDataandalertsData, respectively.featuresUnderCursorhelper variable to store the number of features under the cursor. Now, the cursor only resets when that var is equal to 0, resolving the issue.isAlertvariable based on "Alert ID" field to differentiate alerts from Mapeo data, and use that to conditionally show/hide Media for each.Download,Feature,Map,mapFunctions(related toLegend) to get Mapeo data to work for the respective tasks in each component and/or look nicer.Features, conditionally render a fielddata_sourceas a header. (For now, I just assume that it exists in the database table; would like to think through if this possible to introduce in frizzle.)transformDatato render thecreatedandmodifiedfields as legible dates in the sidebar.mapFunctions, I introduced new functionprepareCoordinatesForSelectedFeatureto rewrite a Mapeo [long,lat] coordinate to show as lat, long in the sidebar instead (e.g. for usage in Google Maps).What I'm not doing here