
Pittsburgh Bus Bunching (2016) - dthal
http://bunching.github.io/
======
et-al
On a tangental note, another HN user posted another visualisation a few months
back which I quite enjoyed:

 _Why do buses bunch?_ : [http://setosa.io/bus/](http://setosa.io/bus/)

~~~
mnw21cam
Indeed. You can do all sorts of complicated analysis of where, when, and how
frequently buses bunch. But the explanation is very simple - like magnets,
buses attract each other, in a positive feedback loop. As long as the waiting
time at each bus stop depends on the number of passengers that have to get on
and off, then buses will always bunch. This is caused by the bus schedule
being tight, so the bus has to keep on driving to stay on time. The problem
will be worse the more frequent the service is.

The solution is also very simple. Stop the waiting time at each bus stop
depending on the number of passengers that get on or off. Slacken the
timetable, so that every few stops the bus waits for a minute to match the
schedule.

On bus routes with very frequent service, for instance every 10 minutes or
more frequent, there is no longer really any need to have a timetable - it
will be a bigger win for the customer to just make sure the buses don't bunch
than it is to actually publish a timetable. In this case, you may want to
implement a negative feedback loop based on vehicle tracking. Most buses are
remotely tracked now anyway, so it shouldn't be too hard to return a signal to
each bus saying either "carry on as normal" or "you're too close to the bus in
front, wait a bit at the next stop".

This is basically the one problem that needs to be solved for buses to not be
rubbish, and it is so simple to do so.

~~~
stephengillie
> _" you're too close to the bus in front, wait a bit at the next stop"_

That's one way to infuriate the passengers on the waiting bus.

~~~
mnw21cam
Not if it's something like 20 seconds.

~~~
stephengillie
Those will be a very tense 20 seconds. A big sign with a clock will help
manage those expectations.

------
exogeny
Pittsburgh is a super interesting city from a transportation logistics and
efficiency perspective. It's got an extremely difficult topography mixed with
a rather obstinate electorate that has routinely de-prioritized mass transit.

This particular piece emphasizes what anyone who attended CMU could tell you -
if you're going to take the 62C anytime during rush hour, you better learn to
hold your breath.

~~~
cornellwright
61C, and it will come sooner or later at rush hour, but there's no point in
looking at the schedule.

~~~
arendtio
For a while the bus schedule for my daily bus to work was "every 2 to 7
minutes" (no kidding). Do I have to add that sometimes you had to wait 20
minutes for the next bus (but then came 3)? ;-)

------
remarkEon
Love this. I’ve experienced bus bunching in several cities at this point (LA,
DC, and now Seattle). It seems to be a known failure mode of metro transit
planning. First step is understanding what your problem space looks like.
Curious to know what anyone here thinks could be a solution. I doubt skipping
stops is one. I suspect that speed controls are probably the way to go.

Edit: kudos to doing this in R. I’ve done other city analysis stuff in R and I
keep coming back to it for one off things like this.

~~~
andreareina
Disclaimer: not a transportation engineer.

I wonder what it would look like if departure times were enforced in the
don't-leave-before direction. Then giving enough time between scheduled stops
that e.g. 90% of buses traveling that stretch can make it in time _for that
day /time combination_. I realize that doesn't mean that 90% of trips will be
on-time due to how failures will cascade, but it should eventually catch up
due to the slack provided.

The big question is whether people will accept the increased latency (and
total trip times) for less variance in waiting time and trip time.

~~~
cimmanom
As a bus rider whose drivers on one route sometimes do this, I loathe it.

The problem is that the route timing is designed for a specific traffic and
ridership level. The actual time to run the route can vary by a factor of 3 or
more depending on whether it’s before, during, or after rush hour.

The route timing is designed for after rush hour traffic levels, when it takes
about 45-50 min to travel from my stop to my office stop. During rush hour,
this trip can take 90 minutes. Before rush hour, it can take 20 on a good day.

So now, if I leave before rush hour, a commute that could be 20 minutes
becomes 50 minutes. On a bus that is scheduled to arrive every 7 minutes - so
bunching means waiting 15-20 minutes for a bus: LESS commuter time wasted by
bunching than is spent sticking strictly to the schedule.

On buses that run even more frequently (one every 2-3 or 3-5 min during rush
hour), this would be ridiculous. People aren’t catching the bus on a schedule
- they just walk out the door whenever they’re ready, and expect a bus to turn
up within a few minutes.

On a bus that’s scheduled to run once every 20 min (and you can wait an hour
for a bus if they bunch), people are more invested in the schedule. I don’t
actually _trust_ the schedule at all unless within a few stops of the start of
the route, and usually use the “just walk out the door” method anyway; but
would appreciate and use the schedule if it were reliable.

So: as a bus rider I might support this, but they would have to fix the
schedules. Create and enforce bus lanes. Run more buses - so that even when
you get more riders than usual they can carry all the passengers at rush hour
without being so packed that it takes 5 min to cram each new passenger aboard
and half the bus has to debark to let someone off the middle. Then a little
bit of traffic is less likely to create bunching.

~~~
andreareina
I probably didn't do a good job of explaining it, but fixing the schedule was
part of the suggestion. So for your example, rush hour timing would allow ~50
minutes between your stops, then after that only 20 minutes.

------
arendtio
> how do we make this better?

Just teach the bus drivers to let the empty busses overtake the crowded one.

It won't solve the pauses when there will be no bus coming, but at least it
increases the passenger comfort by a good margin and the average speed by
which the bunch travels increases too.

~~~
bsder
As I commented elsewhere, passing is not always an option in Pittsburgh.

> Pittsburgh, however, as an unusual misfeature in that the single bus lane
> goes the wrong way against one way traffic (3 lanes of cars going one way--1
> lane of bus going the opposite) for a non-trivial amount of length flagged
> as "hotspots".

~~~
arendtio
It doesn't have to be _always_ an option. The bunch is moving so it is enough
if every third stop offers an overtaking opportunity.

But yes, that going against the flow doesn't make overtakings any easier.

------
scarejunba
Tognar visualization dude. Is there an easy library that helps put together
stuff like that or is it custom?

On mobile so can't inspect.

~~~
blauditore
Inspecting it shows that D3[0] and CARTO(.js)[1] are being used.

[0]: [https://d3js.org/](https://d3js.org/)

[1]: [https://carto.com/docs/carto-engine/carto-
js/](https://carto.com/docs/carto-engine/carto-js/)

------
dthal
Its striking how much less bunching there is on the two routes (P/G) that
operate in exclusive right-of-way.

~~~
bsder
A lot fewer stops through much less popular areas.

The worst bunching occurs downtown and right in front of the University of
Pittsburgh.

And, Pitt is going to cause bunching at discrete times when classes end.

------
scandox
In Dublin (Ireland) the drivers at Dublin Bus call this polling (or
poling...not sure of spelling).

The explanation given to me by a former driver is very simple. When a driver
is very hungover or in bad form for one reason or another they poll the other
bus so they get light duty.

------
paulsutter
Naive question: when buses are bunching, can't the front bus skip stops that
are not needed for dropoffs? (the driver would have to announce that
passengers need to request their stops of course).

~~~
ISL
The challenge is arranging for those at the stop to understand what's going
on. It is disconcerting to have the #75 bus go past without stopping when
you're waiting for a #75 bus.

~~~
ghshephard
Trivially solved if the bus has a digital display - just show “out of service”
in the front bus once bunching starts to occur.

------
duxup
Anyway to use this to predict when you should wait for the next bus so you can
ride more comfortably?

------
nebstrebor
I see this phenomenon in airport parking shuttles ... more frequently than I
would like.

