Later that afternoon, it was the M train.
Judging from the tweets, what’s worse than having train delays is not knowing when and where they occur. While goodservice.io is pretty good at detecting abnormal headways due to bunching or service after residual delays, it did not do a very good job at detecting delays as they were happening.
In my previous post, I explained how goodservice.io uses countdown clock data (i.e. GTFS-RT) as provided publicly by the MTA, to figure out train headways. What if we use the same information to figure out if trains are not moving?
To illustrate what I mean, remember that goodservice.io uses the differences in estimated arrival times to figure out the headway between each train.
Using this same information, we can deduce that there’s a delay if the train arrival times keep moving forward.
Now, we keep track of the train that is at the front of each line and if the current estimated arrival time for that train to arrive at the final station exceeds 5 minutes of its initial estimate, then we flag it as a delay.
Putting this code into action, I have been testing this feature for the last week. Yesterday, it was able to catch a delay on the Culver line, affecting the F and G trains.
I was able to detect this delay five minutes before it was post on the MTA website.
This feature not only detects stalled trains, but also when trains are running slower than normal. Either scenario would result in the estimated arrival time being pushed back. By being more proactive about delays, we can plan our trips better.