This adds a couple elements that were missing from the handling of non-US speed limits. PR #899 handled importing speed limits for segments that are in km/h and converting them to mph for the analysis, but there's also the default residential speed limit, which we get for US cities using state and city FIPS codes, and there's the box on the map that shows the default limit. This adds an alternative way to provide the speed limit, and adjusts the calculation used by the legend to round km/h values to the nearest 5.
The new way to enter a default residential speed limit for is as a field on the neighborhood. Here's what the form looks like now for a non-US city:
The field only shows up for non-US cities, to avoid confusion between the two ways of setting a value (if they should somehow both get set, the model will allow that and the analysis will prefer the value from the new field rather than the FIPS code table). It gets provided to the analysis and used in the section of import_osm.sh where the speed limit is looked up and saved. From there, it acts the same as the current setup--gets stored in the database for use within the analysis, then exported to a tiny CSV file, then imported into the AnalysisJob instance for use on the frontend.
Here's how it shows up on the frontend:
Notes
This PR also includes a couple tweaks to the development tooling, both related to increasing available disk space on the virtual machine. One expands the size of the filesystem inside the VM, the other changes the run-local-analysis script to remove containers automatically, so they don't stick around and fill up the disk after repeated testing.
Make or edit a non-US neighborhood and fill in the default speed limit. It should load that value and when you view the results on the frontend, it should show up on the map as shown above.
Other scnenarios (non-US cities with no value for the new field, US cities with or without city FIPS codes) should work as before
Overview
This adds a couple elements that were missing from the handling of non-US speed limits. PR #899 handled importing speed limits for segments that are in km/h and converting them to mph for the analysis, but there's also the default residential speed limit, which we get for US cities using state and city FIPS codes, and there's the box on the map that shows the default limit. This adds an alternative way to provide the speed limit, and adjusts the calculation used by the legend to round km/h values to the nearest 5.
The new way to enter a default residential speed limit for is as a field on the neighborhood. Here's what the form looks like now for a non-US city:
The field only shows up for non-US cities, to avoid confusion between the two ways of setting a value (if they should somehow both get set, the model will allow that and the analysis will prefer the value from the new field rather than the FIPS code table). It gets provided to the analysis and used in the section of
import_osm.shwhere the speed limit is looked up and saved. From there, it acts the same as the current setup--gets stored in the database for use within the analysis, then exported to a tiny CSV file, then imported into the AnalysisJob instance for use on the frontend.Here's how it shows up on the frontend:
Notes
This PR also includes a couple tweaks to the development tooling, both related to increasing available disk space on the virtual machine. One expands the size of the filesystem inside the VM, the other changes the
run-local-analysisscript to remove containers automatically, so they don't stick around and fill up the disk after repeated testing.Testing Instructions
I pushed these changes in a test branch (https://github.com/azavea/pfb-network-connectivity/tree/test/non-us-speed-limit-badge), so they're currently up on staging.
For testing locally:
Checklist