SOLVING THE PROBLEM OF BUS BUNCHING
Bus bunching is the phenomena of two or more buses on the same route being too close together. My opponent is going around saying that AC Transit need only implement “headway-based scheduling” to eliminate the problem of bus bunching.
In “clock scheduling”, each driver tries to be at given points on the route at specific times, according to the published schedule. With headway-based scheduling, the published schedules only say that buses will be along every X minutes, so drivers need to know how to maintain that interval. Headway based scheduling makes sense for short circulator routes and frequent express routes such as San Pablo Avenue’s 72R and International Boulevard’s upcoming Bus Rapid Transit line. However, it is no solution to the problem of bus bunching because it requires special route infrastructure to implement properly, and even perfect implementation actually worsens average passenger travel times.
Bunching occurs on high frequency lines when Bus A initially gets behind its fixed schedule due to some unusual circumstance such as loading and unloading several wheelchair passengers, or encountering a traffic accident. Short initial delays can grow quickly over the rest of the route because the “dwell time” at each stop gets ever larger with increased passenger boarding and discharging. As a result, Bus B eventually catches up to Bus A; and for the 51A, even Bus C might eventually catch up. That is why bunching usually occurs toward to end of a line.
My opponent’s solution is to program a computer to anticipate the bunching and somehow make Bus B slow down by waiting at the stops. How much to make it slow down, and when to have others begin slowing down, requires that the computer not only know the exact location of each bus, but have the ability to communicate increasingly frequent slow down commands to following drivers. Right now, AC Transit’s NextBus real time arrival predictions are not reliable enough for the former, and have no means of doing the latter. But even if those capabilities did exist, it would only be to the detriment of Bus B’s passengers.
After Bus A slows to a point where the computer begins telling B’s driver to slow down, B’s riders then get to sit at stops for no apparent reason, suffering longer trip times. And those waiting at stops immediately ahead of B get to wait that much longer. Tragically, all of that waiting does nothing to relieve the riders already suffering on Bus A. With bunching, at least those B riders who boarded early and get off before B meets A, have normal trip times.
In actuality, the only reason to prevent bunching by slowing B early is political. For observers on the street it may be less embarrassing to AC, but it comes at the cost of less efficient bus service for its riders.
The real solution is one I conceived and call “bump and run” in which Bus B’s driver, upon catching up to Bus A, passes A and begins boarding passengers from the upcoming stops; giving those passengers an earlier bus because, unlike A, B is not over-loaded with passengers needing to be discharged. Similarly, Bus A’s passengers, waiting for discharge, get a faster ride because the upcoming stops are free of boarders.
The only decision required for this solution is determining whether Bus B’s driver can assume Bus A’s schedule for the return trip, or even the rest of the shift, should she so desire. That would require a protocol to be developed by the driver’s committee that works with AC operations management. And that protocol probably needs to wait until AC has its new more accurate GPS system in place next year, so schedule switches can be automatically tracked. I hope to keep working with our scheduling department and the A.T.U to see that done.