The site is a very simple Dancer app running in Starman on an EC2 instance. The data comes from ProximoBus (http://proximobus.appspot.com/), a lightweight JSON-format wrapper for NextMuni's API.
Three things contribute to a route being "fucked":
- Percentage of vehicles on the route marked as delayed by NextBus
- Size of the smallest gap between vehicles running in the same direction ('bunching')
- Size of the largest gap between vehicles running in the same direction (the other effect of bunching)
Thanks for this! My dream Muni app would show the average time it's currently taking to get through the Market underground section (where I see most of the bottlenecks, esp. on the N). This is a good proxy in the meantime :)
Hmm, that's not a bad metric. Maybe I can write up a special function for the metro lines that computes headways in the Market Street Subway and incorporates those into the status calculations.
The main issue is that until I go through and rewrite the whole thing to do long-polling for every line, it's expensive to compute each route since I have to make several requests to ProximoBus to get all the necessary data. Caching for five minutes helps, but it's still less than ideal.
I've been meaning to do something like this for ages - well done. I didn't look at the source yet - I hope you're storing stats somewhere? I clicked on the L and my wife was skeptical, given the length of time it took her to get home. (The L seems particularly subject to bunching delays, by over-compensating line supervisors...it's common to walk the 1.5 miles home and pass 5, 6, 7 or even 8 trains coming in the opposite direction.)
Heh. Yeah, that's because a good portion of all the lines listed are rush-hour-only express variants of the main lines, or late-hours skeleton service (for the lettered LRV routes). I'm working on adding information on when each line is scheduled to run and what its expected headway is, so look for the inactive lines to disappear and for info on those that are running to get more accurate!
It isn't the SFMTA themselves -- they contract with an operation called NextBus. NextBus installs GPS tracking devices on the transit vehicles, which radio their route, direction, and position back to a central system that then computes ETAs for all the stops on the route. That info is then exposed via a website, an SMS gateway, custom digital signs at the stops themselves, and via the API. It's incredibly useful to have, and there are half a dozen apps out for iOS and Android that show this info to you on the go.
This is rad. Anyone on here see "Is the L Train Fucked" (http://istheltrainfucked.com)? I hacked that together a month or two ago. I hope we start to see more apps built on public transpo APIs!
Love the simple interface. I have been giving a site like this thought for the past six months. I like that you haven't focused on "is it on schedule" but more "how long am I going to wait" I would love a distribution of the space between busses and trains at specific stops. For example, for the N line, at Cole & Carl, show me the frequency distribution of time between trains (and include an indication of what it's supposed to be). When three appear all within 5 minutes, I know someone is in for a very long wait.
23 comments
[ 3.1 ms ] story [ 61.6 ms ] threadFor the curious:
The site is a very simple Dancer app running in Starman on an EC2 instance. The data comes from ProximoBus (http://proximobus.appspot.com/), a lightweight JSON-format wrapper for NextMuni's API.
Three things contribute to a route being "fucked": - Percentage of vehicles on the route marked as delayed by NextBus - Size of the smallest gap between vehicles running in the same direction ('bunching') - Size of the largest gap between vehicles running in the same direction (the other effect of bunching)
Code is up on github: https://github.com/skimbrel/how-fucked-is-muni Enjoy!
The main issue is that until I go through and rewrite the whole thing to do long-polling for every line, it's expensive to compute each route since I have to make several requests to ProximoBus to get all the necessary data. Caching for five minutes helps, but it's still less than ideal.
Most of the routes referenced are here: http://www.sfmta.com/cms/asystem/routelist.php
edit: also on github --> http://github.com/jgv/is-the-l-train-fucked