I want to get from here

1. Algorithm for finding optimal paths in a public transit network with Real-Time Data I want to get from here on buses and trains We introduce a new algorithm which overcomes the problem of computing shortest paths in a transit network which pulls real-time data from a third-party Application Programming Interface (API) with real-time information and I want directions FAST!(3 sec on my mobile phone) 28 41 To Here Our first thought was: let’s build a graph of the transit network (bus stops as nodes, and real-time travel times as links) and run Djikstra’s! Problem: We can’t retrieve all link travel times from the real-time API at once*there are restrictions on how often programs can hit the API. Retrieving travel times for all links would take > 1 min for large transit agencies Why real-time data in trip planning? More accurate predictions for trip time Better suggestions for alternative routes Customer Satisfaction We need information from third party sources < 1% Less satisfied 7% No Change Real-Time Transit Trip Planner route configurations locations of bus stops sequence of stops visited We have to intelligently retrieve only a subset of estimated arrivals at particular bus stops. 91% Schedule-Based Transit Trip Planner 85% 48% Much more satfisfied 44% Somewhat more satfisfied Percentage which Transit Trip Planners under-estimate actual trip time How do we determine these bus stops? First, consider these observations: 1. If the origin and destination are not served by the same bus route, humans intuitively plan trips by finding transfer points to connect between bus routes. 2. The set of feasible paths from any bus stop along Route X to any bus stop along Route Y is a subset of all feasible paths from the origin station of Route X to the terminus station of Route Y. Based on these observations, build a lookup table for all possible paths from the origin of every bus route to the terminus of every other bus route. real-time arrival API estimated arrival to bus stop Jariyasunant et al, (2010) “Mobile Transit Trip Planning with Real-Time Data” Proceedings of Transportation Research Board 2010. Change in satisfaction of public transit Ferris, B., Watkins, K., and Borning, A. (2010) "OneBusAway: Results from Providing Real-Time Arrival Information for Public Transit." Proceedings of CHI 2010. Algorithm Flowchart Preparing Data Real-Time API Create Route Configurations Extract route, direction, stop, latitude, longitude, sequence #, and agency Link Bus Stops with Real-Time feed Each stop must be linked to a real-time URL by an unique stopcode Refine Route Configurations See Figure 4 in paper Route Configurations GTFS files Static Precomputation Pre-computation of Lookup Tables Build Geolocation Lookup Table Store a list of bus stops with their latitude and longitude Build Service-Time Lookup Table Store a list of the hours of the day each bus route is running Find Transfer Points and Routes List of pairs of stops within a reasonable transfer distance (is arbitrarily chosen at half a mile) Build Path Lookup Table Store all paths within 4 transfers the origin stop of every bus route to the terminus of every bus route in each direction. Exclude paths that take two transfers more than any existing feasible paths between an O-D. Geo-Location Database Service-Time Database Path Lookup Database Real-Time Origin-Destination Query Real-Time Retrieve Pre-computed Paths Find Nearest Stops look up running transit routes within ½ mile Remove Irrelevant Paths not all paths are physically possible to be made Calculate real-time travel times Retrieve Real-Time Information From API and sort routes by shortest travel time 5 shortest paths ≈0.1 secs ≈0.3 secs ≈0.1 secs ≈1.5 secs Real-Time API How do we measure the performance of the algorithm? Our Experiment: 770,000 tests in 77 different cities Does it scale? The size of the lookup table increases polynomially as the number of routes served by a transit agency grows Pick random origin & destination in a city, compute directions and record: By measuring the response time < 3 seconds D.C. 63 million pre-computed paths 1.2 GB needed to store in memory 312 routes served 194,000 unique bus stop/route-direction pairs Size of lookup table for 77 different cities The response time depends on the number of possible paths (from Origin to Destination) retrieved from the path lookup database which then affects the number of bus stop predictions needed from the real-time API Response time Number of paths pulled from lookup table Number of requests sent to real-time API Repeat x10000 for each city Total # of paths in lookup table 29 This example: 3 paths 8 arrival requests J The size of the bubbles represents the number of total bus stops in the transit network Number of possible paths (x100) 14 99% Percentile: 1900 paths. 50% Percentile: 224 paths 49 Number of bus stop predictions needed from real-time API Number of routes served 29 The two graphs to the left and right represent 10,000 Simulations for Washington D.C. 99% Percentile: 82 queries. 50% Percentile: 26 queries Bus stop predictions needed from real-time API for different walking radii *Washington D.C. was the largest network (number of transit routes operated) route configuration files were available for, and therefore was tested to show the algorithm working in the worst-case scenario The performance of the algorithm is affected most by the time to query the real-time API, the bottleneck. The number of queries increases with the amount of distance people are willing to catch a bus. Frequency (out of 10,0000) Result of 10,000 simulations in Washington D.C. Jerald Jariyasunant, Eric Mai, Raja Sengupta. U.C. Berkeley Predictions needed