Visualizing Transit Reliability

Reliability is one of those essential features of transit that you can’t take a picture of.  It’s an overwhelming issue in the lives of transit customers but can seem abstract to others who make transit policy.  And it’s a major issue in many transit systems.

Poor reliability of buses has many causes, mostly having to do with the traffic congestion and other causes of random delay to which they’re exposed.  But when a rail line runs in an exclusive right of way, never interacting with traffic, there aren’t a lot of excuses.

The Miami organization Transit Alliance has done a nice visualization of transit reliability on that city’s rail transit system.  It looks at the system right now and shows how many trains are running late.  It’s important to note here that late does not mean behind schedule.  It means that the maximum wait time is longer than scheduled, by a given number of minutes.  (That’s the only rational way to talk about reliability in high-frequency services.)

Some insitute really needs to create a database of reliability info across many agencies, searchable many ways — and always based on this headway reliability rather than on-time performance.  Most transit agencies now have real time vehicle location feeds, and they are already released in standard formats for use by apps.  Yet we see remarkably few of these kinds of analytics that could help people understand the severity of the reliability problem — even on services like grade-separated heavy rail that have few external causes of delay.

 

 

7 Responses to Visualizing Transit Reliability

  1. SXS February 7, 2018 at 11:10 am #

    One way I’ve thought about to visualize transit reliability for buses – specifically to visualize bus bunching on routes like SEPTA’s super popular and super bunched 47 – would be to create an app using GPS location data that projects each bus route as a perfect circle with the buses moving in real time around the circle. If you have ten buses running on the route, you’d expect that the buses would be relatively spaced out. But when buses bunch as they invariably do you’d see that the balance of the system would go way out of whack. Since bus routes are frequently linear following the same route in each direction, even live bus location data doesn’t show the problem very well. Bus bunching is not very well known (outside transit circles), so I think this would be a great way to visualize the problem and spur interest in coming up with solutions.

  2. david vartanoff February 7, 2018 at 11:30 am #

    FWIW Stephen Bauman has been posting AWOL stats of the NYC system over at subchat.com for most of the last month. Trains scheduled but not operated are obviously more evil than merely late ones.

  3. baselle February 7, 2018 at 11:41 am #

    Per SXS’s comment – doesn’t super popular and super bunched help create a downward spiral of reliability? I see it in Seattle where most transit riders will take the first bus on a route even if next bus on that route is visible. I know I’ve been known to comment on it in a friendly way to other riders, “nah, I’ll get a seat on the next one thirty seconds from now that I can see.” Lately I’ve been noticing that other riders look off in the distance and not necessarily take the first one at hand.

    Visualizing the reliability might get riders to behave strategically. If they can iron-clad depend on reliability, you might see more transit users gamble on the second bus more readily and even out the bunching behavior.

  4. Fbfree February 9, 2018 at 12:46 pm #

    There’s quite a number of questions that one can answer with these types of analysis. There’s the obvious, such as measuring wasted value due to delays, or evaluating the benefit of right-of-way improvements. On the more obscure side, I’m sure there’s some operators out there who’d pay to find out which shifts to pick to have the most reliable working schedule.

    For Toronto, Steve Munro has performed a valiant effort to present the effects of delays, but he hasn’t really found a good solution to this problem. I had tried automating delay plot generation for Chicago, but didn’t have time to work out all the bugs or perform more in-depth analytics.

    The problem in presentation is that at least some data reduction has to be performed in order to make a readable presentation, and how that data is reduced depends on what one wishes to understand. For instance, a plot showing journey time variation will be different than wait time variation at a stop, and neither of those will hint at the cause or location of a delay along a route.

  5. Carl February 11, 2018 at 2:46 pm #

    While headway management may be desirable for buses if done well, it is not appropriate for grade-separated rail nor frequencies of 10 minutes or worse. Especially for 10 minute frequencies and below, regular users prefer to be able to time when they need to arrive at a bus or rail station, rather than arrive randomly and wait.

    In addition when transferring from a frequent line to a low frequency (e.g. half hourly or hourly service) I want and need my frequent line to adhere to a schedule. I can build in the buffer that works for me in case there is a delay, factoring in the consequence of missing the connection (airplane departure or first date, big buffer; visiting mom or sister, assume schedule adherence.) But if my first frequent service no longer adheres to a schedule, I am now penalized on every single ride, I can neither plan connections nor plan my arrival to scheduled service.

    I’d say that for service below 6 mins (10 per hour) you can use headway management with disregard for schedules. For 10 minute service (6 per hour) you should follow the schedule, even at the cost of bunching. At 7.5 minutes (8 per hour) I’m on the fence but I think I prefer schedule since it’s still pretty easy for most to remember.

    And why not design and operate services that stay on schedule – instill discipline and make the schedules realistic. And get the city to create queue jumps and dedicated lanes that make that possible.

  6. asdf2 February 11, 2018 at 10:26 pm #

    In the modern world where people have smartphones to tell them where each of the buses are in realtime, it is best for buses to use a schedule to decide when to leave the terminal, but once en route, they should just drive to the end – any artificially induced delay along a route simply serves to make it more difficult for the app to predict when a given bus is going to show up. (You can’t just code headway management into the app because it’s just too much of a guessing game which drivers will decide to wait when the bus in front gets late, and at which bus stop along the route they will decide to wait at).

    When I need to catch a bus, I generally don’t pay much attention to the published schedule – I just look at the real-time and decide if a bus is worth waiting for or not. Adding in the possibility of artificially-induced delays to a bus because the one in front of it got delayed just makes things more complicated. It can also be absolutely maddening to get stuck on a bus that decides to just sit there in the middle of the road for a few minutes, for no good reason.

    Furthermore, artificial delays on the bus at the back of a bunch don’t do anything to reduce the wait times for people trying to get on the bus in front of it, and, if anything, may make things worse. If you just let buses bunch, the delay of any particular bus is bounded by how long it takes for the bus behind it to pass it (after which, the buses leapfrog each other, stopping at only every other stop, so everything moves more quickly). Artificially delay the bus in back to maintain desired headway, now there’s nothing the stop the bus front from falling further and further behind.

  7. Willem February 14, 2018 at 9:28 am #

    Love it when reliability comes along – maybe I can incorporate some of these visualizations in my thesis 🙂 Thanks Jarrett!