Hacker News new | past | comments | ask | show | jobs | submit login
Pittsburgh Bus Bunching (2016) (bunching.github.io)
82 points by dthal on July 24, 2018 | hide | past | favorite | 60 comments



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/


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.


Milwaukee does this, you get on the bus by when an app says it's gonna arrive around there. They also put express buses[1] on the busy routes which don't make the exact same stops. Two ways to split the difference on bunching I guess.

If you check out their site[2] you can click on the Route Map button and see the buses run in real time.

[1] https://urbanmilwaukee.com/2014/12/03/eyes-on-milwaukee-new-...

[2] https://www.ridemcts.com/routes-schedules/greenline


>and it is so simple to do so.

Except for the little hiccup of organizational politics in government bureaucracies that needs to be solved or side stepped as a prerequisite. If you can do that tons of "hard" problems are easy to solve.


Most bus services that I know are private companies, so this wouldn't be a problem.


In Boston on the T-lines they will just announce that the subway is expressing to skip the next two stations. Every one who wants to get off at the skip station needs to exit and catch the train behind.


> "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.


Not if it's something like 20 seconds.


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


Buses can also pass each other or not stop at every stop. If two of the same line's buses hit a stop at once, maybe the second rolls on by to the next stop unless they have passengers to drop off? The example is a little too simplistic but does illustrate how rapidly the issue can appear.


Yep and I also went to University of Pittsburgh. Not a coincidence.


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.


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


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)? ;-)


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.


Skipping stops is something our buses used to do (rural Netherlands), this would usually happen if one bus was late so the next one was right behind it. Makes no sense for a full bus to stop when nobody has to get out when there's an empty one driving the same route right behind it.

Experienced bus travelers would often know when there'd be two buses in a row, too. And of course the bus drivers would point it out.


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.


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.


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.


I suspect they would. Predictability in public transit is hugely important. People base a lot of their routines on these schedules. I also think enforcing stop/departure times is probably a much more elegant solution than controlling speed.


I wonder what kind of speed limit you have in mind. When Bus bunching occurs the bicycles are often faster than the busses ;-)


Buses are typically late due to variations in traffic. The solution is to prioritize bus traffic. Use dedicated bus lanes. Cars could drive in the bus lane, but must pull over or switch lanes if a bus is approaching. Traffic signals switch to green when a bus is approaching.


Not only does Pittsburgh have dedicated bus lanes, they also have dedicated bus roads; roads where cars are not allowed to drive on (many are deprecated light rail lines)


I don’t see this often in SF (at least on the E-W routes). Lots of factors though: overcapacity, mass-transit friendly population, express buses, sparse car traffic, linear routes, etc.


> 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.


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".


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.


Another potential solution during rush hour would be route splitting - each alternating bus on the route is assigned to stop at even/odd stops (e.g. bus 1 stops at 1/3/5.., bus 2 stop at 2/4/6.., 3 at 1/3/5..). This assumes that the extra walking distance between stops isn't too unacceptable (and has some issues for people with disabilities).

Socialising the idea to the passengers is also probably difficult.


They already do that in NYC. It doesn’t help because the following stops are full of extra passengers and the crowds on the buses quickly equalize while they remain bunched.


I didn't state it that clear, but I am well aware that adding overtaking to the equation doesn't solve the bunching problem .

But the bunching itself is not a problem. The problems are the effects it causes like:

1. crowded busses

2. arrival delays

Overtanking has a major impact on the first effect as you have stated too, the 'crowds on the buses quickly equalize'. The impact on the second effect depends on some other parameters. If all busses are crowded there will be no effect at all, but if only a few busses are crowded (the front busses) and the busses behind them are empty, there can be a positive effect on the arrival delays too (the worst case drop off time will be lower).

So I would not say 'it does not help' as it certainly decreases the negative effects.


I suspect this isn’t as easy as you think. Where I am (Seattle) an empty bus overtaking a full one isn’t really feasible given traffic and lane size considerations.


Well, maybe you should consider banning cars from the city center then. ;-)

I mean, where I live, busses manage to overtake in a one lane for each direction scenario (which is theoretically complicated, but works out in practice as traffics lights can give you chances to use the opposite lane). Nevertheless, what is important is that the front bus waits until the busses behind him have taken the lead. Otherwise there will be very few opportunities to safely overtake the front bus.


I don’t think banning cars would do much, to be honest. Banning cars might actually exacerbate the problem as the folks who would otherwise drive out of convenience now take the bus. Structurally, on many streets there literally just isn’t another lane available for an empty bus to overtake a full one. Getting rid of more cars, while a noble goal imo, won’t fix that.


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.


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

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

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


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


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.


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.


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).


Ah this is an interesting idea. Passengers already have to request when they want to get off. I'm assuming you mean if no one wants to get off, a bunched up bus skips a stop because a bus behind it says "I'm behind you, I'll take this stop."

That would mostly work, but the problem in Pittsburgh at least is the bus bunching happens between related but not quite identical routes. For example, the 61A, 61B, 61C, and 61D all run down Forbes Ave, and frequently get bunched there. But then later in their routes, they fork: two go one direction, and two go the other direction. For many passengers, it doesn't matter which one they take. But for other passengers, it has to be a 61A etc.


Technically it isn’t bunching if it is for different routes. The standard industry definition for bunching as I understand it is when multiple buses for the same route are bunched up.

As is hinted at by the paper, bunching is generally caused by factors such as traffic which makes it hard to actually eliminate. Transit agencies have tried various solutions to the problem and it is very much a work in progress. One thing I have noticed is that transit agencies tend to have sub-optimal data for their service so they tend to be slow at fixing scheduling related issues.


Ah, maybe that’s the formal definition. But it’s still frustrating to be at a bus waiting for a late bus and then see a 61A, B, and C all in a line, knowing that any of them will get you to dinner :P


The real issue is that the BACK bus needs to pass the front bus and move ahead a couple of stops.

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".

This means that while automobile drivers using the bus lane is a self-correcting problem, a bus cannot pass another bus in those areas.

(I call the wrong way bus lane a "misfeature" because it regularly results in out-of-towners winding up dead because they didn't look both directions on a "one way" street. This is particularly tragic when the out-of-towner is someone who is visiting Children's Hospital because their child is being treated for some very aggressive disease.)


I suspect the odds that there is no one that wants to alight at a particular stop on a fully crowded bus are rather slim, both mathematically and anecdotally.


Do they really stop everywhere unconditionally? In the UK almost all stops are by request, for both boarding and alighting.


As another comment noted, even if the stops aren’t unconditional the probability that no one will pull the cord for any particular stop on a crowded bus is near zero.


This assumes all stops are equally popular, but that's very unlikely.

I suspect a lot of bunching is caused by buses having to perform complicated manoeuvres around car traffic because of poor stop positioning. In Barcelona what many lines do is skip stops right before left-hand turns (the line isn't even listed at that stop). This way the bus can switch lanes well ahead of time and avoid having to wait for traffic to go though all lanes. This works because most lines stop every two blocks, so you never have to walk too far for the next stop.


But then it's a simple case of the front bus not letting anyone on (only opens it's rear doors). Everyone then gets on the 2nd bus. The people become spread out between the buses and the probability of not always needing to stop increases. That does obviously only work where your bus design allows it and also to some extent, your drivers being wise to it.


Controlling which doors open as dependent on how full the route is and how bunched the buses are is just going to confuse passengers and make for a horrible rider experience. I sympathize with the idea though, as veteran riders know to move to the back as the bus nears your stop.


I mentioned it as it's what sometimes happens in London when the bus is very crowded. They do it because at the point it makes sense the rider experience is already horrible. For most buses it is front doors for getting on and rear (middle) for off. It's already independently controlled so it is not extra complication. But I do appreciate other places don't have the same system.


And the passengers not being idiots who feel entitled to exit through whichever door is nearer their ultimate destination. Also the infuriated passengers who’ve been waiting for half an hour or more not taking bricks and bats to the driver’s window.


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.


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


Someone I know was standing at a bus stop on the phone to me, when the expected bus sailed straight past without stopping. This person then started running after the bus and shouting, trying to get its attention to make it stop. This meant that when the next bus came along 1 minute later, they were not at a bus stop, and that one went straight past as well. All while I was trying to tell them that the only reason a bus would go straight past is if there is another one just behind it, and to just sit tight at the bus stop. He/she/it was not in the slightest bit amused.


If there's a bus 250m behind it that confusion will not be long lived.


I have seen this happen sometimes, but there are always passengers who forget to signal and then run to the front shouting for the driver to stop. Not worth the hassle.


Aside from infuriating the waiting passengers at those stops... my experience is that a packed bus will have someone getting off at every single stop anyway.


Yes, he can. But here is the problem: the front bus has most likely the most passengers and therefore the lowest chance of skipping a stop ;-)


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


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




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: