Preparing for updating the database

Some steps are necessary to setup a new database update.

Make sure the indicator naming scheme is being followed

Right now this is a process that I do internally after the raw database is provided, but for the future is important to follow this standard. Each indicator will have the following structure: type_indicatorcode_year. The type can be city, walk, bike, or transit. The indicatorcode can be determined accordingly. Right now, the suggested naming structure for each indicator is (based on how they are named right now):

type	current_name	proposed_name	parent
city	density_2024	city_popdensity_2024	popdensity
city	total_pop_2024	city_popdensitytotal_2024	popdensity
city	block_density_2024	city_blockdensity_2024	blockdensity
bike	pnpb_2024	bike_pnpb_2024	pnpb
bike	pnab_2024	bike_pnpbpnab_2024	pnpb
bike	all_bikeways_km_2024	bike_pnpbabikewayskm_2024	pnpb
bike	protected_bikeways_km_2024	bike_pnpbpbikewayskm_2024	pnpb
walk	h.s_2024	walk_pns_2024	pns
walk	healthcare_2024	walk_pnspnh_2024	pns
walk	n_points_healthcare_2024	walk_pnshealthpoints_2024	pns
walk	schools_2024	walk_pnspne_2024	pns
walk	n_points_schools_2024	walk_pnsschoolspoints_2024	pns
walk	carfree_2024	walk_pncf_2024	pncf
walk	people_not_near_highways_2024	walk_pnnhighways_2024	pnnhighways
walk	highway_km_2024	walk_pnnhighwayskm_2024	pnnhighways
transit	pnft_2024	transit_pnft_2024	pnft
transit	n_points_transit_pnft_2024	transit_pnftpoints_2024	pnft
transit	PNrT_all_2024	transit_pnrt_2024	pnrt
transit	PNrT_(mrt/brt/lrt)_2024	transit_pnrt(mrt/brt/lrt)_2024	pnrt
transit	km_(mrt/brt/lrt)_2024	transit_pnrtkm(mrt/brt/lrt)_2024	pnrt
transit	rtr_(mrt/brt/lrt)_2024	transit_pnrtrtr(mrt/brt/lrt)_2024	pnrt
transit	pnst_2024	transit_pnst_2024	pnst

Each indicator must follow the naming scheme in the column proposed_name. Also, note that each indicator is part of a "parent" indicator. The parent column will determine the children, with the first indicator of each parent representing the main indicator.

If you are adding new indicators

Adding new indicators to the support spreadsheets

Right now there are two support Google Sheets: one with general information about the indicators, and the other with the overlay info for each indicator. As you add a new indicator, you should add the information about the new indicator as such:

Atlas indicators

Information to be added to the spreadsheet:

• indicator_type: if it's city, walk, bike or transit. Please arrange the table to get it to order;
• indicator_code: define code for the indicator;
• indicator_name: set a name;
• indicator_transformation: the transformation to be applied to the indicator. If it's percent, thousand etc
• indicator_unit: the unit;
• multi_year: if the indicator has multiple years of data or not. Important for visualizing in the comparison panel. This probably would be deprecated next year since we are doing an update on the data and every indicator will have multiple years.

Atlas overlays

This table will determine Information to be added to the spreadsheet:

• indicator: the indicator_code from the previous spreadsheet. This code is related to the "parent" indicator;
• overlay_dir: the directory where this overlay is located;
• geom_type: the geometry type;
• overlay_label: the overlay label (may be the same as the indicator_name from the previous spreadsheet);
• overlay_show: if this overlay should be shown as default when the indicator is selected;
• format: the file format/origin of the overlay. Right now the options are tif (the overlay is rendered after a .tif file), fgb (the overlay is rendered after a .fgb file) or mapbox (the overlay is stored as mapbox tile). This may change in the future;
• mapbox_id: for the mapbox format, the mapbox id from the style that contains the overlay. The mapbox styles are currently stored at my account;
• fill: the color to fill the overlay. Note that for the population/block density this is not required because they are filled based on the value of each raster. The remaining columns should be filled automatically.