lossyrob
commented
4 years ago @bitner in our discussion Monday we discussed a possible hitch around using geohash as feature IDs - I was unsure whether the requirement of the integer ID was on the tippecanoe side or with mapbox-gl. Unfortunately it's mapbox-gl-js, which makes fishnet cells not referable by their geohash on the front end for the setFeatureState logic. However there is a FID that is unique inside each fishnet, so potentially if we don't plan on showing multiple fishnets we can just use that FID in a layer containing only that urban area's geom, where those FIDs would line up with the JSON data structure returned by the API.
Other than fishnets, it looks like there's WB_ADM*_CO for admin0, admin1 and admin2 that could be used to construct unique IDs for each feature that would be unique to whichever scope we need them to be (ie a globally unique integer ID could be constructed from those three values if needed).
How the front end works now, we're baking static tiles with individual layers for admin0 and admin1, so we'd need the feature IDs to be unique within those layers. Once we move to dynamically generated vector tiles, though, we wouldn't have that constraint - we'd be adding and removing layers per parent area (per admin0 area for showing admin1 boundaries, etc). And if we're getting data from the API in the above format, where the data is keyed by feature IDs from some API for a specific indicator layer and parent admin0/admin1 region, the front end wouldn't have a problem matching those keys up with whatever ID schema you'd like to implement.
bitner
This issue describes the data utilized by the initial version of the HNP dashboard as well as the formats used. This should help inform the features of the API so that the dashboard can be transitioned to pulling data from the API.
Currently the dashboard pulls from static JSON files and vector tiles that are served through a Netlify deployment.
The vector tiles have two layers: admin0 and admin1. These are keyed by a unique integer ID - these are unique across both layers. The feature properties include total population data. admin0 and and admin1 boundaries and population data are from the GOST team's data (from the OneDrive data delivery). Geometries are supplemented with Natural Earth where geometries are not available. Currently we are only processing Brazil provinces for the admin1 layer. Future work will include a layer for urban areas.
The data we are using currently comes from the IHME COVID-19 projection dataset and JHU case data. IHME contains time-series projection data as well as summary information for some admin0 and admin1 boundaries. JHU has daily case, death, and recovery counts per admin0.
The data format for the time series is similar between JHU and IHME. Below is a description of the formats:
IHME time series data
where
IHME summary data
The summary data is the same as the timeseries data, without the values being split across dates. There are no levels implemented:
JHU data
This is similar to IHME time series data without the concept of levels. It includes the metrics "cases", "deaths", "active", and "recovered", where active is computed from cases and recovered.
Configuration data
In each case we need to know class breaks in order to style the polygons on the map. The "configuration" file for the datasets describes the dates that the time series data applies to (in order to populate the time slider) and the class breaks for both total and per-capita metrics. Currently only the per-capita data is used in the dashboard.
IHME Config
Where
JHU Config