This issue came up after investigating a report that adding a rail network alongside a bus network had the unexpected effect of reducing accessibility (jobs within x minutes) calculated by Pandana for certain locations.
The cause turned out to be a workflow error, but it's something we should fix in the demo notebook and explain better in the documentation.
Problem
Suppose you have job counts by census block. You want to link these to an UrbanAccess network so that you can calculate how many jobs are accessible within x minutes from each location.
If you link each block to the closest node in the integrated network, some of the job counts may end up associated with transit station nodes rather than street nodes. Transit nodes typically have an impedance for people coming from other networks (to capture headways), making the jobs less accessible than if they were associated with a neighboring street node.
Solution
The solution is to make sure jobs (or other destinations) are only assigned to the subset of nodes in the integrated graph that come from the base network. Code examples here: https://github.com/ual/pandana-urbanaccess-issue
Next steps
The UrbanAccess demo notebook currently does this incorrectly, so we should fix it: simple_example.ipynb
We should add a note to the documentation as well.
Identifying the correct subnetwork currently requires some manual filtering, but it would be easy to automate with a new UrbanAccess helper function or two!
This issue came up after investigating a report that adding a rail network alongside a bus network had the unexpected effect of reducing accessibility (jobs within x minutes) calculated by Pandana for certain locations.
The cause turned out to be a workflow error, but it's something we should fix in the demo notebook and explain better in the documentation.
Problem
Suppose you have job counts by census block. You want to link these to an UrbanAccess network so that you can calculate how many jobs are accessible within x minutes from each location.
If you link each block to the closest node in the integrated network, some of the job counts may end up associated with transit station nodes rather than street nodes. Transit nodes typically have an impedance for people coming from other networks (to capture headways), making the jobs less accessible than if they were associated with a neighboring street node.
Solution
The solution is to make sure jobs (or other destinations) are only assigned to the subset of nodes in the integrated graph that come from the base network. Code examples here: https://github.com/ual/pandana-urbanaccess-issue
Next steps
The UrbanAccess demo notebook currently does this incorrectly, so we should fix it: simple_example.ipynb
We should add a note to the documentation as well.
Identifying the correct subnetwork currently requires some manual filtering, but it would be easy to automate with a new UrbanAccess helper function or two!