How to Get Ahead of Train Traffic
Analogous to how maps show how well traffic is moving on the roads, goodservice.io now displays subway tracks’ traffic conditions.
I travel from Williamsburg to Washington Heights every Sunday to take piano lessons. According to Google Maps, this 13-mile journey on the L and A trains should take 55 minutes. However, I have been finding myself having to leave earlier just to get there on time. Much earlier. In fact, if I leave any later than 2:45pm, chances are I would be late for my 4pm lesson. I’d get it if I had been unlucky and kept missing trains, but the L train runs quite frequently, even on weekends (until last week anyway), and I’m still late even if I catch my connection with the A train.
Anyone who regularly takes the subway on weekends should be familiar with what I described. Due to service changes involving track work, weekend service on the New York City subway can be erratic and slow. But there hasn’t been a way to really plan around it, aside from not using transit at all.
The limitation with current transit navigation apps is that even if they incorporate real-time transit information, they only use it for vehicle departure time (i.e. the time it predicts you can get on a vehicle), but everything after that is dependent on the scheduled data, making the assumption that the transit vehicles are always running on schedule. If we can’t even depend on the schedule for the vehicle’s departure time, how can we depend on it for the vehicle’s runtime?
Our feature to detect delays has made goodservice.io successful at figuring out when trains are stalled. What if the trains are still moving, but just at a slower speed?
Just as car navigation apps like Waze and Google Maps provide hints on estimated time added to your trip because of traffic conditions, goodservice.io has added a new metric to determine if trips are taking longer than expected: Traffic Conditions.
How It Works
As previously explained, goodservice.io’s train frequency data is powered by the MTA’s scheduled data from its static feeds and real-time data from its real-time feeds. Using the same data source, we can also determine trains’ speeds. From the scheduled data, we can figure out how long trains should take to complete its run, and from the real-time data, we can estimate how long a train actually took to complete its run.
The New York City subway is a complex system of trains merging in and out of its tracks. goodservice.io already divides routes into segments or physical lines where the same routes are typically expected to travel together for some distance. Lexington Avenue Line, for example, is defined in the app as the physical tracks between Brooklyn Bridge–City Hall and 125 St, a 7-mile 4-track segment where during the day, no. 4 and 5 trains share the express tracks, and the no. 6 train run on the local tracks. If no. 4 trains are running slow there, chances are no. 5 trains are running slow too, since these trains cannot go around each other.
To measure the Traffic Conditions metric, we are comparing the scheduled runtime (i.e. the amount of time that is typically quoted in transit navigation apps) between the two ends of each line, with the average actual runtimes of all trains completed their journey between the two ends in the last 30 minutes. +0% means it trains are running to schedule; the higher the number, the longer trips have been taking.
What about Planned Service Changes?
Oh yes, weekend subway riders are certainly familiar with service changes that allow track work to be happen. Some of these changes can be the factors of when service is slow. To capture this information during the times when it is most useful, we certainly need to adapt the metric to service changes. Since we are comparing all trains running on the same line against the scheduled runtimes of all trains scheduled to run, it is inherently route-agnostic.
For example, in this past weekend, Coney Island-bound F trains were running on the E between Jackson Heights–Roosevelt Avenue and Canal Street, then on the A to Jay Street–MetroTech. In other words, it is running local on 8 Avenue Line via 53 Street and through Cranberry Street Tunnel (via Chambers Street) between Jackson Heights–Roosevelt Avenue and Jay Street–MetroTech. Now, it wouldn’t make sense to compare these F trips’ runtimes to regularly scheduled F trips because they run on a completely different route. Instead, we can break the routing down into segments and compare runtimes for all trains in each segment.
In this example, we can compare all E and F trains currently running on 53 Street with the weekend scheduled runtime of E trains that are normally scheduled to run there. Similarly, we can compare all C, E and F trains running local on 8 Avenue with the scheduled runtimes of C and E trains there. Lastly, we can compare all A, C and F trains running through Cranberry Street Tunnel (specifically the segment of the 8 Avenue Line between Canal Street and Jay Street–MetroTech) with the scheduled runtimes of A and C trains that are supposed to run.
New Views
With all this new data we are generating, we’ve added new ways to interpret them. A new Slow Zones tab is added to display the current slowest lines, allowing you to easily glance which parts of the subway system are currently running slow.
Pretty graphs have been added too, so you can view Traffic Conditions across 24 hours for the last 7 days. Generally, weekday runtimes seem to be pretty consistent, but you can definitely see things get a bit wild over the weekends and overnight. To get there, just click on the Stats tab in any Line view.
goodservice.io is an open-source project to provide New York City subway riders a more detailed and up-to-date status page using public APIs. Contributions are welcome on GitHub. Feedback can be directed to @_blahblahblah or @goodservice_io on Twitter.
