Repository navigation
Analysis with defined transit service area (limited walk distance to transit stops) #42
Description
Description of the bug
I stepped through the demo notebook using our own transit feed and walk network. The code worked well but when inspecting result looks like places far away from transit network also got significant job counts.
My understanding is that after combining transit and walk network, pandana query will search jobs disregard network types. So transit accessibility analysis could end up including travel by walk + transit, transit only and walk only mode. But in general, transit accessibility study targets people lives within certain distance to transit service. So places beyond reasonable walking distance/time to transit should be filtered out from the analysis. And transit should be one of the major/necessary mode in the travel.
This issue is similar to issue 38 but for a different reason. Also, after filtering far away walk network nodes, the indicator locations need to be filtered as well (get_node_ids with distance limits).
Let me know if anything is wrong with my analysis or interpretation.
Environment
-
Operating system:
-
Python version:
-
UrbanAccess version:
-
UrbanAccess required packages versions (optional):
Paste the code that reproduces the issue here:
# place code herePaste the error message (if applicable):
# place error message here
Activity
Eh2406 commentedon Apr 9, 2018
Specifically are previous analysis looked at 45min travel time of witch only max of 15min is walk time. We are not sure how to reproduce that with urbanaccess.
li-guangyu commentedon Apr 9, 2018
One method of filtering is to use similar procedures in UrbanAccess (kdtree nearest neighbor plus vincenty distance). Then filtered walk nodes by selected distance. I already have that part of codes in my notebook. But then filtering parcels ( I am using parcel data instead of Census blocks) cannot be done since the get_node_ids is not on projected system.
So here's a thought, convert lats and lons in transit feeds and process all calculation using projected system. I think that will simplify and speed up the kdtree search as well.
sablanchard commentedon Apr 9, 2018
Thanks @semcogli and @Eh2406. @semcogli your assessment is correct the default analysis considers: travel by walk + transit, transit only and walk only. Adding in a function to perform the type of filter you suggest would be a great addition and nice feature. As a start, sharing a notebook outlining simple examples of your proposed workflow would be good as we consider pending updates to the package.