Why do buses bunch? | Hacker News Reader

Why do buses bunch?

setosa.io

216 pointslewis500154 comments

I commute in LA and observe (and am impacted) by this regularly; so much so, that I've been meaning to write the municipal operator about solving the issue, or at least reduce the tendency (attractor?).

My mitigation idea: When the buses become bunched; the forward bus should switch to 'Disembark Only' mode. (Most modern buses I've seen have a preset to post this on the LED signage). This way it can pass all the stops with folks waiting and (we hope) will make enough time up to get far enough down the line to remain un-bunched.

Then, by some condition (e.g.,"back to within 5 minutes of posted schedule") switch back to normal "pickup & drop-off" mode.

It's very cool to see someone else noticing and thinking about this phenomena.

To quote the great thinker Yogi Berra, "You can observe a lot just by watching."

I think this would work well, but my gut reaction is that a passenger who is already annoyed at a late bus watching that bus just go right on by would be unappreciative.

until they realize that there is a bus coming within 5 minutes? Also, this means that the bus is less likely to be late.

It may be that one day, you'll be standing at a bus stop with no shelter in 46c weather with no water or hat waiting for a bus that is 20 minutes late.

If and when that happens, you'll understand why I once hit the external emergency door override for a bus that tried to drop off a passenger but not let me on, and gave the busdriver an earful when he tried to close the door on my arm.

Not everyone lives in temperate zones.

Maybe you should call emergency services when you are caught out unprepared for the weather...

Another person who lives in a temperate climate. Let me break it down further, oh inexperienced one:

Unless you're a pensioner, that's not going to kill you, but any person who would willingly leave another person in that situation for even 5 minutes is an arsehole.

Then surely any person who delays the bus for many future passengers down the route is a much bigger arsehole?

Yeah. That'd be the bus driver. The guy responsible for driving the bus on time.

Isn't that what he was trying to do before you forced yourself aboard?

A bus drivers job is to pick up all passengers on the route and keep the bus running on time simultaneously.

Are you really such a moron that you can't figure out for yourself that a bus service that can't do both is worthless?

> Are you really such a moron

There's no need for that.

I certainly wouldn't blame the bus for not being prepared for the weather.

The weather is omnipresent, my northern friend, and when the buses are running on time it's not a problem to only bring a 600mil coke bottle of water with you, but you will go through that if the bus goes AWOL.

It's not practical to bring a camelback everywhere in case the bus decides not to show up, but I don't expect you to know that, since you clearly turn the air-conditioning on at 25.

A couple of tweaks that might make it less problematic for you:

1. Bus #1's signage updates so it doesn't show the bus route externally; it's no longer "your" bus, so you aren't upset when it passes by

2. Bus #2 (which is ostensibly no more than half a block away) has an N% discount for passengers (where N increases according to demand).

3. When Bus #1 gets "bumped" (metaphorically) by Bus #2, bus company regulations have it pull over and let Bus #2 pass it; therefore, the less-crowded Bus #2 can pick up more of the waiting passengers. [Edit: Oh; I see this has been covered in some other comments already.]

Discount is a great idea - but if passengers are regular riders (monthly bus pass) - it's not clear what you can offer them for their annoyance.

Offer them taxi tickets :)

> it's no longer "your" bus, so you aren't upset when it passes by

It's not always so easy to trick people. For me, in SF, there are often bus stops with either only one bus line, or with multiple bus lines that will all take me to my destination.

"Out of Service" or "Charter".

Getting caught lying will make it even worse.

Technically, the signage is correct ;-)

> 1. Bus #1's signage updates so it doesn't show the bus route externally; it's no longer "your" bus, so you aren't upset when it passes by

They do that sometimes here in Brisbane, Australia.

Perhaps changing the signage to something like "Bus Full - Next bus in 5 min"

Just tell me the next bus is just a minute or 2 away and much less crowded.

This happens in Japan too. The first bus is full with people packed in leaning on each other. Wait 20 seconds the next bus is empty and I get a seat.

The problem is I don't know they are bunched when the first bus arrives. I assume that's the only bus and that if don't get on it will be another 10 - 20 mins for the next bus. If I knew the busses were bunched I'd be more than happy to take the less crowded bus.

Your comment makes me think of this comic: https://xkcd.com/277/

I often times have the same thoughts, but I have a feeling there are lots of considerations that we aren't taking into account when we create our solutions.

I thought of that yesterday when they turned on these new meters on I5 that seemed to do nothing.

One thing the DoT could do to assuage our negative feelings is put the methodology out in the public after it's implemented. Show how the sausage is made, if you will. Then again, it's probably people who would otherwise be predisposed to looking up how a simulation would run in this case that would be less likely to whine in the first place. So it probably doesn't really matter, other than on principle.

Why not open-source the methodology before it's implemented? They might get good feedback.

Are you talking about ramp metering?

If so, I was involved in a trial in Melbourne, Australia on a major highway there. In peak times, it can actually improve travel times by 50% and massively reduce congestion around the choke points you get just ahead of on-ramps.

It depends on what algorithm they use to determine timing though - this was a coordinated, dynamic algorithm, but sometimes they are just manually set which isn't as good.

I am! Do you have any datasets that you can release that I could look at? Or what the algorithms looked like? I'd love to be armed with some real facts the next time I get annoyed or my coworkers start complaining.

Here's the best one I can find: http://ersilia.net/origami/docs/vicroads.pdf

Up to 58% increase in average speed in one test, which was probably the figure I was thinking of (it was a while ago!)

One thing the DoT could do to assuage our negative feelings is put the methodology out in the public after it's implemented.

It likely is public - there may be an environmental assessment (EA), Environmental Impact Statement (EIS) or Environmental Impact Report (EIR) that will have an appendix containing the detailed traffic engineering study behind the metering. It's probably based on MUTCD guidelines [0].

Assuming you are referring to I-5 through CA, a Google search for "california ramp metering study" brings up a lot of studies and documentations sponsored by Caltrans.

[0] http://mutcd.fhwa.dot.gov/htm/2009/part4/part4i.htm

I'm actually referring to I-5 up here south of Seattle...right outside JBLM where I work. I have looked and unfortunately I haven't found anything. I did find a bunch of stuff that talks about ramp metering at large, but nothing specifically about the on-ramps here that just got metered.

Anecdotally, traffic inside JBLM has been significantly negatively effected because of this. I read in another comment that ramp metering speeds up traffic on the freeway...I really hope that's the case. Because it's really annoying to sit in my car while trying to leave and I hope I get to make that up on the aggregate. And to my earlier point...it isn't immediately clear that I will...because the methodology isn't open.

I was thinking of https://xkcd.com/793/ Just jump in and fix it, can't take more than an afternoon right?

I feel a bit weird about this, because my father actually worked for the local highway department and I ended up learning about the stuff that goes into road design and engineering... and most of the payoff of that is that I complain when I see stuff done wrong.

And it's not just light timing; my single biggest gripe is when I can tell from driving on a road that its speed limit has been set significantly differently from its design speed (in either direction -- there are some local streets obviously set too low, but also some highway stretches that are obviously set too high).

I'd say there are a lot of local streets with speed limits to high, designed for speeds MUCH to high.

http://www.strongtowns.org/journal/2010/11/22/confessions-of...

Ehhh... that guy seems a bit off.

It is true that often residents demand something be done to force the average speed of traffic way below the design speed of the street, but generally it's not because some engineer slapped a major arterial into a cozy residential neighborhood. Rather, the common pattern is the residents moved in because they liked being conveniently on some minor artery that would get them to/from work quickly, but then decided after moving in that it had to change into a quiet residential street so their kids could go out and play in it.

The result, if the neighborhood can pull off enough local political clout, is usually that a street designed for good amounts of traffic doing 40+ mph starts getting its limit lowered to 35, then 30, then 25, then roundabouts and speed humps start showing up to enforce it, and you just get a mess.

Yes and no. The neighborhood where I live was laid out eighty or ninety years ago. Most families probably had a car by 1940, but I doubt many had two. Most had garages, some had driveways but no garage. Now I suspect that we are unusual in being a two-adult household with one car. A neighbor across the way has four vehicles--three cars and a pickup truck, all of which they must park on the street.

The increase in cars per household means that for a good ways in every direction, any side street will have cars parked on both sides. Two ordinary sized American cars can pass each other in what is left, but drivers usually find it safer to look for an unparked space where one can pull over a little. Twenty-five miles per hour does not feel slow on these streets (particularly from the right front seat).

You are completely correct about the residents wishing to slow things down. Thirty years ago one could get onto 13th St. NW in downtown Washington, and with a bit of luck hit no red lights all the way to Maryland. Now there are stop signs sprinkled between the lights. In Chevy Chase, there is I think one path left that takes one through the neighborhoods from Jones Bridge Road to Beach Drive where once there were many, the rest now blocked by barriers.

Ha, i feel the same way when, for some reason, for work experience I got stuck in the local government road planning department. I was bored out of my brain but I did learn about corner radius for speeds, acceptable road crests, minimum sighting distance for signs at various speeds, acceptable on-ramp lengths and on and on.

And all it ever did was highlight to me how often somene did a crap job. And usually there was always fresh evidence of crashes in the vicinity. The people who crashed were probably told they were bad drivers,m without realising half the problem was that some desk ok key was phoning it in she the road was planned, or the government was too lazy/broke to fix obvious problems.

It would be quite neat if you could toggle this behavior on or off in this simulation, to see it in action.

buses in san francisco do this. i have no idea how well it's working for them, but as a passenger, it's pretty frustrating to see your bus pass you by when you've been waiting 10 minutes already.

I regularly use Muni line 29. At least a couple of times a week, commute hour buses do this. Usually it works out okay for two reasons:

1. The next bus is right around the corner or I have my transit App to give an idea about delay if I cannot see the next bus yet. generally the delay is of teh order of 2 ~ 3 minutes.

2. The next bus is also has less people and the journey is thus more pleasant.

Things do screw up at times though. This weekend, a driver did not stop and indicated that there was a bus following him. The App showed the next bus was 20 minutes behind. I had to catch a different bus after that. I hope this does not happen on working days.

I don't think they're implementing this idea. The only times I have seen a bus fly by a stop is when the bus is clearly completely full.

Clearly you have not ridden the buses in LA then. I did this for 2 years to get about the westside. Even imagining that people would read the sign, or know the English language clearly enough to do so, is laughable. The average bus rider in my small experience (not talking about the actual average, that I do not know) is typically Spanish speaking, is crazy drugged out/drunk, or will not care no matter how much you try to reason with them. I kid you not, I have seen on more than one occasion a homeless person heave feces at the buses that pass them by when they are too full to legally allow more people on. Maybe not most, but enough of the population of passengers are too nuts to reason with that trying to enforce a disembark only policy will lead to deaths of drivers (not that the drivers are all that different than passengers either, you cannot believe that some are considered qualified to drive by any rational person). At the end of the day, trying to deal with real people leads to unreal problems.

Post the sign in Spanish and English, then?

> At the end of the day, trying to deal with real people leads to unreal problems.

It's funny you say this, because you've managed to reduce real people (transit riders) into an unreal stereotype ("crazy drugged out/drunk").

Buses in Vancouver already do this (or at least they did a few years ago), they'll switch the sign to "BUS FOLLOWING" or "DROP OFF ONLY".

Buses in LA actually do this. It says "Discharge Only".

If you ever waited for a bus in LA for an hour only to see it come and not stop for you, you would feel differently. Even though a lot of people take the bus in LA, buses aren't really the cities priority.

It has considerably improved in the 10 years I've had to take them but they are hardly reliable. You cannot take the bus without planning ahead.

For the bunching problem, we can't simply add more buses because they will end up being empty. We can't have too few because it already feels like there are too few.

I really hope there is a solution in the near future.

>I really hope there is a solution in the near future.

Some time ago I've read about an experiment (in one of Scandinavian countries I believe) involving buses with the routes completely depending on the passenger's needs (via mobile apps). Unfortunately can't find the link right now.

I believe its Kutsuplus: https://kutsuplus.fi/home

The Metrobuses in Washington do this at times, though sometimes it is because there really is no room left.

Note how this would all go away if the empty buses could pass the full buses. Which they usually can, since even on single-lane roads, the bus stop is out of the way of traffic.

But then there are trolleybuses. When the busses are all hooked to a single overhead cable run, as is common in places like Vancouver, the driver of one trolleybus would have to de-latch and then re-latch their "rabbit ears" (i.e. get out of the bus twice) in order to pass another trolleybus. Needless to say, this is uncommon. (Someone on HN: please, come up with a trolley pole design that can hot-pass another trolley pole pair while remaining on the line, and sell it to cities.)

Trolley buses are common on hilly routes where electricity provides torque needed to navigate steep grades. Very common in the pacific northwest (Seattle) and much of the alps (e.g. Lausanne).

Buses tend to bunch in Beijing also, bad traffic prevents them from passing very well.

And San Francisco.

They also have real trolleys just for this purpose. Unfortunately, those have become tourist attractions.

In Chicago on very rare occasions when the train is running late they will have an impromptu "express" train where they skip the next 4 or 5 stops. They announce it so you know not to get on the train if your stop is being skipped.

It seems like such a huge deal for them to do this - it's very rare. It must be a giant pain, even though it makes a lot of sense. Not only does it get the train back on schedule, but it reduces the riders on that train, which further speeds it up. If there was an easy, intelligent way to allow the bus to go into "express" mode and alert the riders then the busses could avoid getting bunched up.

I'm not sure how often you're on the CTA but I've found trains running express during rush hour to be a pretty common occurrence.

There are scheduled express trains during rush hours.

Given that trains share track, switching, and a whole mess of other stuff, I'm really surprised they do this at all. I suspect it's only possible with significantly automated / computerized controls, or by having a secondary switching and traffic control pattern that they can run.

>Note how this would all go away if the empty buses could pass the full buses.

It's more complicated than that and has to be managed carefully.

Here's what happens in the unmanaged case:

- The empty bus passes the full bus

- There are passengers waiting at the next stop

- The empty bus stops to pick them up

- There are no passengers waiting

- The full bus typically doesn't have to stop

- The full bus passes the empty bus

Now these buses are irrevocably bunched.

P.S. This site doesn't work for me at all.

A fairly full bus will still stop at many stops (maybe not all) even if nobody is waiting to get on, because there will be people waiting to get off.

One frequent problem is with lines that run between two places (e.g. the downtown core and a stadium during a game), where virtually everybody will get on at the first stop and ride until the last stop. This plays havoc on the needs of regular commuters who live between the two stops. Usually, express runs are created that only go between the two stops, to siphon off some of that traffic—but if the regular bus arrives before the express bus, people will get on it in order to go to the terminal stop nevertheless.

Really, almost all transit problems could be solved with etiquette about not (always) getting on the first bus to arrive at your stop.

> Really, almost all transit problems could be solved with etiquette about not (always) getting on the first bus to arrive at your stop.

I think that not etiquette but rules is the solution here. If I make up my own standards of politeness for which bus I should board, then it's likely that I will inadvertently conflict with the transit system's standards, making things worse for others or for myself than the greedy approach.

To be blunt, I'm not going nobly to sacrifice my bus based on my guess of what's efficient. If, however, the transit system clearly indicated what was appropriate—via its rules—then I would be much more motivated to obey them, based on the idea that the rules would have been set up to maximise throughput. (Live status monitors, which not all cities have, also help a lot here.)

Yea, maybe not even rules -- we can do better those days than giving out a set of rules for users and expecting them to follow.

The ideal I think would be a "global optimizer" for commuter traffic (with fairness included in the objective function, i.e. nobody is screwed too much in the name of the commons), and appropriate individual-level tracking and statistics. That way you could be told:

"You should hop-in in the bus X which will take only Y minutes.", updated in real time. If you don't follow the recommendation maybe you pay a more expensive fare and the system adjusts.

> almost all transit problems could be solved with etiquette about not (always) getting on the first bus to arrive at your stop.

Spoken like someone who doesn't ride the bus.

As discussed below, it's common that people want to get off at the same place, and so not all stops are used to disembark.

Also, disembarking is much quicker than embarking[1], so this won't make a big enough difference. The bus behind will be at least as fast than the bus in front.

[1]Your choice of reasons: baby carriages don't like to go up; people have to pay to get on; the location of the bus door is/isn't predictable in advance; etc.

Exactly. A method that does work is to make the full bus exit-only: no new passengers are allowed to enter the bus. You keep that bus exit-only until it has caught up to its schedule. This also works fine with trolley buses. Unfortunately this is hard to match with human psychology of the people trying to enter a bus.

I've seen this happen, but it works better w/ human psychology if the buses are frequent (and people know they are frequent). If it's a bus with a typical headway of 5-10 minutes then it's generally ok; if buses only come 2-3 times per hour, being skipped to improve the spacing of buses is really annoying/inconvenient since passengers aren't confident of another bus coming soon.

An alternative sometimes used in systems that have infrequent buses is to schedule the route with some slack in the schedule, so the bus is almost always "ahead of schedule". Then it waits at certain designated timepoints until the scheduled time, which re-syncs it with the schedule. This slows down the route overall (since the bus is periodically just sitting at a timepoint for a few minutes), but improves its predictability / adherence to the published schedule. I think I first ran across this in Miami.

On routes that are heavily front-loaded (a connection from a metro line to a neighbourhood the metro doesn't reach, for example), this can result in the first five-to-ten stops on the route effectively being knocked out during rush hour. Anybody who actually wants to catch the bus has to walk ten blocks over to the first stop.

A display at the bus stop showing when the next 3-5 buses are going to stop approximately solves the problem

It really helps. In New York some subway lines have this and some do not. On the lines that do not, you sometimes hear the conductor announce "there is a train immediately behind this one" but it's not nearly as effective as when everyone waiting on the platform has been able to see that.

You would only do this during times when the throughput of the system is still higher than the arrival rate of people. It's essentially trading throughput for reduced latency. During rush hour you need throughput.

> P.S. This site doesn't work for me at all.

Use Chrome. Doesn't work on Firefox.

I don't quite note how it would all go away with less full buses passing more full buses.

For one thing, it would be incorrect for an empty bus to pass a full bus - a full bus can't take any more passengers, and the people who don't fit on the full bus would have to wait even longer, for the next bus again.

Secondly, people get off at stops, not just get on. The bus that overtakes won't get a big lead, because it probably has to stop anyway. It can only leave when it looks like the front bus is going to fit all the passengers.

Thirdly, the bunching that has already occurred (to make it possible for one bus to overtake another) means that the bus stops ahead have far more people at them. Instead of merely bunching together, one full bus followed by one empty bus, you'd have two fairly full buses leap-frogging one another.

The only way get back to a situation where the buses are on opposite sides again, minimizing variance in bus wait time, is to have a bus pause when it gets too far ahead of schedule.

Note that bunching isn't actually the problem—in fact, bus runs are frequently planned in bunches, with two shorter busses arriving in series simulating a the arrival of a single double-length bus.

The problem, in practice, is people cramming into the nearly-full first bus of a bunch (and delaying the bus further as people slowly fight their way off and on), with another nearly-empty bus following along with nobody getting on it.

This problem would go away if people could be trained to wait for the second bus in the "bunch", rather than getting on the lead one. But, since that change-of-perspective is unlikely to happen, "two fairly full busses leap-frogging one-another" is actually a good solution. It's load-balancing, basically.

For bus stops with live status displays, this is reasonable. In cities where there's no indication of when the next bus is, there's no live-monitoring facility available on the phone, and the driver's response to "when is the next bus?" is "dunno"—you can bet I'll cram on that bus.

Generally, realtime over-the-air updates of transit status are simply an amazing UX upgrade.

Completely changes the experience.

Why are buses planned to arrive in bunches? Double-length buses save a driver, but if you have two single-length buses, what's the advantage to bunching?

Rush hour, bursty demand.

And let's not even get started on how inefficient the whole rush hour concept is.

it would be incorrect for an empty bus to pass a full bus

You've got it precisely backwards.

If the empty bus passes the full bus, then the empty bus is picking up passengers, while the full bus, arriving at freshly cleared stops, only unloads.

Eventually the loading factor levels out and the problem's cleared

Indeed, so the empty bus will slow down and the full bus will speed up a little (as it still has to drop off passengers), and they will meet and switch places again; so the two buses will start leap-frogging each other all the time, as GP described. So they will tend to stay together, and not spread out as desired.

Even in the worst case performance of leapfrogging, you still have an additional busload of throughput that you didn't have before.

You don't permit them to switch.

That's even worse. They will just keep together, and the bus at the back (which was the initial full bus) will have to wait for the bus at the front without any good reason.

No, that's exactly what you're trying to accomplish.

You're already got a headway interruption. Both buses are arriving at stops after a longer-than-usual interval. That means there are more passengers waiting.

You've put the empty bus ahead of the full one. It picks up the waiting passengers.

The full bus trails, briefly, it discharges passengers, but loads none (or at worst, a very few).

This continues either to the end of the line (at which point regular headways are once again established), or, possibly, until the lead bus becomes full. At that point, you might swap positions, but only then.

If you were to put the full bus in the lead because it was "getting delayed", you'd only re-create the problem you initially had: of a full bus trying to load and unload passengers, which happens much more slowly than for an empty bus, while the less loaded bus that can accomplish loadings/unloadings faster trails behind.

Your letting the trailing, full bus lead doesn't save time.

Play with the sim here and see what happens.

Well, I guess you can't make it much better than your method anyway, and it does have the advantage that people will see both buses arrive at nearly the same time, so there's that.

The passing technique for trolleybuses is actually for the lead bus to pull their rabbit ears down and reraise them once the other bus has passed (when I've seen it done, such as the case where one bus has mechanical trouble and is being replaced by another).

When well executed, it's actually a pretty smooth maneuver that takes just a moment of cooperation, but I agree with your (main) point that it's not efficient enough to do in live traffic as a routine thing.

The trolleybuses that Seattle is in the process of ordering are capable of driving off-wire on battery power for quite a ways (enough to bypass a construction detour), and can also detach and reattach themselves without the operator directly manipulating the wires.

When I lived in London, and used buses fairly regularly, I started thinking about ways to improve the service and stop bunching. I considered the reason stated here, and some of the solutions, but later realised that the root cause was that the drivers liked to stop and chat and perhaps play cards with each other at the (presumably unsupervised) "bus station" at the far end of the route. Once I'd observed 3 of them waiting for each other, chatting, and then all leaving at once on the same route, my interest in trying to think of ways to fix the problem waned.

You could give them smartphones to make them less social.

I lived in London and used to ride the 9, which at the time was one of the last routemaster buses.

I also learned that the drivers are comfortable in their chair, and they get paid whether they are late or early, whether they take off smoothly or like a jackrabbit, and whether people are crammed in or left waiting on here stop because they weren't quick enough.

In other words, automation has to be a part of any solution, because the drivers do not care.

I'm sure there are several valuable lessons hidden away in there - concerning assumptions, human factors, jumping to "obvious" solutions without having verified the actual cause of a problem, unintended consequences etc. etc.

Would be interesting to look at a system where it does actually work well and see what's different.

Fwiw a relevant general concept is that of stable vs. unstable equilibria. In a stable equilibrium, small deviations will tend to correct back to the equilibrium, while in an unstable one, small deviations get magnified and the system drifts away from it (absent active intervention). Given some assumptions, such as those implemented by this simulation, evenly spaced buses represent an unstable equilibrium, since a bus slightly early or late will cause an asymmetry in passenger load that pushes things further in the "wrong" direction.

It makes me sad that this doesn't seem to work in Firefox!

Or Safari.

Or IE 11.

going to fix that

Hi Lewis

I too don't run Chrome.

But from what I can see running Firefox, this looks great.

Any ETA on when your site will be fixed for non-Chrome users?

yeah tonite about 9pm

Which time zone?

Some developers who use Chrome don't bother with cross-browser testing, I've noticed. Not sure why but it's a common problem I experience with HN links.

Yet another example of a lazy Chrome dev. This is getting too prevalent.

Google is turning into Microsoft 2000. It is the natural order of things.

Where I live, if a bus gets late enough (or too full) and the driver knows there's another bus right behind, they'll start skipping stops. I don't think that would help in this simulation because people getting on seem to be equally likely to want to get off on each stop, but IME that's not really accurate for most bus routes. People want to get on the bus at all sorts of random places, but 90% of people are getting off at the same two or three stops (transfer point, city center, etc). It would be interesting to see these things would affect the bunching, I think.

There's a bug in that simulator:

    00:12:07.824 "Error: Argument 1 of SVGPathElement.getPointAtLength is not a finite floating-point value.
    [6]</MapCtrl</MapCtrl.prototype.place_bus@http://setosa.io/bus/dist/bundle.js:380:10
    $parseFunctionCall@http://setosa.io/bus/dist/bundle.js:29490:15
    expressionInputWatch@http://setosa.io/bus/dist/bundle.js:29899:31
    $RootScopeProvider/this.$get</Scope.prototype.$digest@http://setosa.io/bus/dist/bundle.js:31386:34
    $RootScopeProvider/this.$get</Scope.prototype.$evalAsync/<@http://setosa.io/bus/dist/bundle.js:31591:15
    completeOutstandingRequest@http://setosa.io/bus/dist/bundle.js:22010:7
    Browser/self.defer/timeoutId<@http://setosa.io/bus/dist/bundle.js:22398:7
    "1 bundle.js:28741:17
    consoleLog/<() bundle.js:28741
    $ExceptionHandlerProvider/this.$get</<() bundle.js:25682
    $RootScopeProvider/this.$get</Scope.prototype.$digest() bundle.js:31412
    $RootScopeProvider/this.$get</Scope.prototype.$evalAsync/<() bundle.js:31591
    completeOutstandingRequest() bundle.js:22010
    Browser/self.defer/timeoutId<() bundle.js:22398

No buses are drawn.

This site/group also did a fantastic visualization on gridlock vs. bottlenecks:

http://setosa.io/blog/2014/09/02/gridlock/

I've never heard of them before, but they have some really amazing things! I am thoroughly impressed.

This is interesting and I like the display.

However, in Firefox (Gentoo 35.0) the buses don't stick to the roads on the turns and seem to go a little slower than intended.

This therefore means that the buses don't bunch at all.

This is an amusing bug as it's pretty much impossible to notice (everything works) but ruins the effect on Firefox.

Now how do we explain how buses seem to arrive and depart just before we arrive to the stop?

This kills the firefox.

For real, though. Buses bunch because this site doesn't render properly. All the buses seem to be stuck off to some corner.

Does anyone know why this doesn't work in Firefox?

Based on the tone of some other responses, I'm guessing because the author of this is literally hitler.

Does anyone have a technical means for Hitler to do this?

Different JS and DOM and CSS engines , so some tight inner loops are a significant factor slower do to missed optimizations.

I believe that to solve this problem, metros in paris have two strategies:

-1 a train that has a train too close before it will idle between stations to restore a reasonable space between trains (problem: all trains go as slow as the "first" train)

-2 a train that has train too close after it will ask all travelers to step out at a station to wait for the next train, then skip a couple of stations to restore a good space between trains (problem: people in the "scarified" train get a big delay)

Is it just me, or did it not actually explain why:

> Bus bunching happens because, if a bus gets delayed, then there will be more people waiting at the next stop than anticipated. The extra passengers' boarding time makes the bus even later, and so on in a vicious cycle.

OK, so I get that buses get delayed. And even more delayed. But why buses "bunch" up and arrive at the same time doesn't seem to be explained anywhere.

This doesn't even seem like an accurate simulation, if bus 1 is unloading/loading at a bus stop and bus 2 catches it, bus 2 waits for bus 1. This makes sense in the context of the website because buses always drop off/pick up passengers when they get to a bus stop. But that isn't how it works in real life, if bus 2 doesn't have to drop off someone while bus 1 is at the stop it will just leapfrog past it.

The fact that busses don't overtake each other seems to be the reason the bunching happens, as soon as the front bus starts slowing down a little it's inevitable bus 2 will catch it and then the situation can't be fixed.

Because as the lead bus gets filled, the following bus has fewer and fewer people to pick up, so it speeds up until it catches the lead bus, which is running later and later due to the passengers overloading, who turned up early for the later bus. The lead bus can't be passed by the following bus, so they bunch.

Buses bunch as they move further along the route as a consequence of having a dwell time (the time spent at the stop) that increases as a result of the number of passengers boarding at each stop increases AND having passengers arrive at each stop randomly. You can reduce bunching effects by:

* loading passengers who have already paid through multiple doors like Curitiba which every transport engineer includes on their honeymoon :)

* having passengers use smart cards rather than cash which is slower

* running infrequent services so passengers read the timetable and do not arrive at the bus stop randomly as their is an incentive to be their at the timetabled time.

The last method is obviously not acceptable in running a service but it highlights the curse of running frequent services. As frequency increases, people's behaviour moves to "turn up and go" rather than read a timetable and the buses bunch. So you in effect trade waiting time, waiting for a timetabled service for bunch delay time. Hence one good reason to go for smart cards or bus platforms where you pay prior to boarding the platform like a train station to speed up loading.

In Chicago, the CTA is rolling out new 2-way communication into buses to allow the dispatcher to try and help alleviate bunching

http://chi.streetsblog.org/2015/05/14/heres-how-new-cta-tech...

NYC Metropolitan Transportation Authority posted a cute 8-bit video about the same problem, but for subways: https://www.youtube.com/watch?v=eShtZSx4kWc

Nice explanation I just wish it went into more detail as to WHO causes the time delay. No bus stop line has stops where the exact amount of people get on every time. It's the fact that the first bus picks up more people (due to rush hour) and those people take more time to get on, request more stops and delay the bus. The time delay is caused by:

Asymmetrical passenger quantity. (usually rush hour)

Which the really nice demo doesn't show (because it wants to show the delay with the passengers as a control). Both bustops have the same number of passengers each in relation to each other. That's just not realistic. In the real world, the asymmetrical passenger quantity causes the delays, not traffic.

But trains generally don't.

Trains are signalled so the waits and delays take place between stations and not at the platform: it takes a while for the delayed train to reach the next station so it won't just sit behind the first train and be of no use.

The stop times for commuter trains are quite consistent because there's no onboard ticketing: people just hop out and then on, and that's it. Tickets are prepurchased or sold by the conductor while the train is moving.

A good portion of the time spent at a stop is spent decelerating and accelerating and not only loading/unloading passenger. Even if there were no passengers, the stop time wouldn't necessarily be substantially shorter.

There's no other traffic which helps keep to the schedules: this cuts down the sources of unexpected delays. Barring track and switch failures, the only source of delay is a huge crowd of passengers leaving and boarding on a single station. Even there, station platforms are quite long and even if some venue were to ooze thousands of people out to the train station at the same time, there's a limit of how many people can realistically populate the whole platform in between trains. So there generally is always some space on the platform to which the existing passengers can still exit, and people waiting on the platform tend to saturate available free space instead of crowding into an unpenetrable flock.

Now, buses could use "soft signalling" to even out the distance between consecutive units. Using travel cards only (either with prepaid monthly periods or by having single-fare smartcard readers onboard) and allowing unloading/loading through all doors at the same time would help. Bus lanes and unconditional traffic light prioritization (bus always gets green light) for public transit are used in many countries. But there's very little to do about the capacity of a bus and the short length of a bus stop.

Even trams are much better: they can take in 3x-5x as many passengers and tram stops are generally much longer, allowing the tram to operate with 6-8 doors instead of 2-3 like a bus. Tram routes are often heavily isolated as well, and run with at least some basic level of traffic light priorities.

"But trains generally don't."

The London subway has real problems with this, because they have so much rolling stock on some lines that any delay cascades back through the chain of trains. On some lines, a 30 second delay will cause the train behind to stop between stations, which means it has to accelerate again, putting it about a minute behind. This can delay several following trains.

The Yamanote line in Tokyo, which is a big loop around the central city, has trains about every 2 minutes. If any train is delayed by 5 seconds, the schedule for all the trains in the loop is slipped back 5 seconds. This maintains spacing.

(Not trying the article's domain against the corporate firewall, sorry)

Sometimes it's because there's traffic going the opposite way. Many buses travel a circuit, so their route ends at its beginning. If your bus is late, maybe it was stuck in traffic an hour ago, and was late to every stop since that traffic.

Traffic itself becomes a travel-time multiplier - driving a car home from some offices, leaving at 3pm would get me home at 3:30. But leaving at 3:15 gets me home at 4. Leaving at 3:30 gets me home at 4:30. It seems to describe a bell curve that maximizes about 5:30 or 6pm.

Why are you afraid to try?

Even cars "bunch" (cause traffic jams) without any apparent reason. It's due to instabilities in traffics caused by reaction times [1].

[1] http://www.sciencedirect.com/science/article/pii/S0167278905...

Direct link: http://www-personal.umich.edu/~orosz/articles/PhysicaDpublis...

Over here in and around Philadelphia I think the main problem is the stoplights. In my commute home I literally have to stop at each and every one and they are sometimes no more than a few hundred feet apart. I always wonder why they can't be synchronized in some way to allow for a more fluid traffic flow, but never the less they seem to like stopping long lines of traffic to allow a single car or two to get out of a shopping center with the priority it seems being given to those in the shopping center.

In the simulation, the back of the bus slides out like a race car in the "S" curve. Don't spill your coffee.

I actually made a small tool to track bus bunching in Chicago.

https://github.com/skatenerd/buses/blob/master/artifacts/hea...

The results were largely depressing, but unsurprising.

hey yall maybe you will like this short paper on dynamic control for bus bunching from my group http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.153...

I must be missing the complexity here. Surely this is.simple, since buses run to a timetable. Hence they can only be on time or late, but never depart earlier than advertised. Hence over time the chances that it will be delayed increases the chances of bunching.

Buses here (Berlin) often depart as soon as they reach the station, which can be early (except on their very first station I guess).

You could argue that they shouldn't, though.

If you ever played Minimetro, the trains always bunch when you put several of them on one line.

Anyone else learn this from scheduling trains / switches in A-Train? =)

Two words Toronto streetcar riders dread: short turn.

Here in Portland I've often seen pairs of bunched busses leapfrogging each other at every stop so that at least they both move faster.

In Lima Peru the bus drivers pay spotters on the street who report flow conditions by cell phone.

They do this in my city too (Bogotá, Colombia). It's actually illegal here, but they do it anyway.

It's bizarre that it would be illegal. For all I know, it might be illegal in Peru too, but it happens, and it works pretty well.

In Lima, the spotters are known as "dateros" (loosely, "data wrangler"). The bus drivers pay them roughly 20 centavos, I think per stop but I'm not certain.

One case where it doesn't work is when certain bus drivers ignore the system and aggressively jump ahead of other buses. Nevertheless, it's pretty smooth.

Doesn't seem to work in my browser. Maybe my address bus bunches with the data bus.

Damn, this is a beautiful site.

Wow, this was the CS101 4th week assignment I had to do (without the graphics).

Hi Lewis.

I really liked this page, but it is consuming too memory and CPU power.

traffic lights...

Where's the button to make the goldbricking union bus driver stop and get out for a smoke break in the middle of the run?

Because bus drivers like to play poker together in the pus station.

I haven't read the article, but I ride the bus a lot. Here is my subjective take: bus drivers get into a very distinct and slow pattern of their bus driving behavior. Slow to do everything, never not taking their break, never attempting to make up for lost time.

So in their daily routine, the traffic between stops is variable, but their little rituals and apathy to the travel plight of passengers is not.

They also like to take up time socializing between driver swaps, which aren't accounted for in bus schedules. Thus the largest factor is bus A may have no traffic, and bus B had a lot, but their stops at each place take the same amount of time, thus they end up clumping when traffic let's one drive between stops faster than the other, who will still be on his break at the Bart station.

The point of the article is that you can generate this behavior in an ideal system without taking into account differences in drivers.

Put simply, small stochastic differences in arrival rates of passengers or initial speed of buses will amplify themselves. If you take three buses and shift the center one in time, you'll end up with one longer gap and one shorter one. The bus with the longer gap will tend to find more people waiting at each stop, while the bus with the shorter gap will find fewer people and move faster. Ultimately, the faster bus will catch the one in front of it and follow it, with zero people getting on at each stop. There will then be a -huge- gap, followed by a very slow bus that has to pick up a ton of people at each stop.

Which pretty much maps to my comment.

  I haven't read the article, but ...

it's an interactive and intuitive explanation of why this happens, and it has nothing to do with anything you mentioned.

"my ignorance is just as good as your knowledge"

Did you really just create a throwaway account to slag on someone else's comment? Please don't do that :/

No, it doesn't. The article says that bunching will happen even with perfect robot drivers. Your comment says that bunching happens because drivers are lazy.

(Also, the article is a tiny flash game and like five sentences of explanation. This isn't tl;dr territory.)

My comment says that this was my subjective experience. People seem to have missed that.

Clearly that means I am incorrect, but it was just what I observed and felt was happening around my commute.

The paper does nothing to dispute the laziness of the drivers :-)

Reply on news.ycombinator.com