search

UDST / urbanaccess

A tool for GTFS transit and OSM pedestrian network accessibility analysis by UrbanSim
https://udst.github.io/urbanaccess/index.html
GNU Affero General Public License v3.0
239 stars 57 forks source link

Analysis with defined transit service area (limited walk distance to transit stops) #42

Open semcogli opened 6 years ago

semcogli commented 6 years ago

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

Paste the code that reproduces the issue here:

# place code here

Paste the error message (if applicable):

# place error message here
Eh2406 commented 6 years ago

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.

semcogli commented 6 years ago

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 commented 6 years ago

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.