Workflow bug: Destinations for accessibility queries should be linked only to the base network

[smmaurer]

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

1. The UrbanAccess demo notebook currently does this incorrectly, so we should fix it: simple_example.ipynb

2. We should add a note to the documentation as well.

3. Identifying the correct subnetwork currently requires some manual filtering, but it would be easy to automate with a new UrbanAccess helper function or two!