[joosters]

What an arrogant article. How can you title something 'How traffic actually works' when you don't examine actual traffic. Instead, make up a simple model, run some code, claim it shows what you want.

It's not like modelling traffic is so insanely hard that we need such simplistic models. Pick as complex a model as you like; we have the computing power to simulate it!

[nether]

He's derived the fundamental diagram of traffic flow: https://en.wikipedia.org/wiki/Fundamental_diagram_of_traffic....

Up next: why F = ma really, really matters for space launches. Experts don't know this!

[hayksaakian]

"1 weird trick for successful space flight"

[angersock]

Lockheed Martin hates this guy!

[leothekim]

If you RTFA, he compares the results of the model to actual data collected by the Federal Highway Administration. Why use a complex model when a simple one suffices?

[msane]

Not a fan of the use of "RTFA".

[analyst74]

What author is trying to argue against is the idea of "smoothing-the-wave", which he does prove in his overly complicated article.

Yes, there is too much rambling for making a point, yes the tone of title is quite arrogant / link-baity.

But this terrible essay did prove the point: smoothing the wave is not going to make you go faster.

[jerf]

I'm not sure who actually thought that "smoothing the wave" did make you actually go faster though, since a moment's thought shows that "going faster" would necessarily involve going through the bumper of the car in front of you. I think it's about a "laminar" traffic flow being a lot less annoying and dangerous to drive in, if you are going to go slow.

I think he fell down on his own argument when he claims that doing that causes a "big traffic jam" downstream of you; how can it, if you're only 10 or 20 seconds max further behind than you otherwise would be? You can only cause that much additional "traffic jam" in the back, and it may well be worth it to create a more laminar flow.

[SilasX]

>I'm not sure who actually thought that "smoothing the wave" did make you actually go faster though,

Probably all the people that passed around the critiqued link and suggested that it gives a way to improve traffic flow?

[j-kidd]

The gist I get from the link is that the act of "smoothing the wave" will not benefit the one who performs the act, but it benefits the drivers behind the lane. You can't fix the traffic jam in front of you, but you can do your part to prevent one from forming behind you.

And that's why people pass around the link.

[SilasX]

Right: like I said -- and like the GGP (jerf) just denied them saying -- the claim is that it will hasten the traffic flow. Individual vs group benefits is beside the point.

[dvanduzer]

He utterly fails to make that point. His simple model explains the idea of maximum throughput / congestion.

It utterly fails to explain the extreme variance in real traffic throughput during congestion. The original article does.

[jliszka]

OP here. That's a really good point. I just think the original article overreached in saying that zipper merging is a "simple cure" for traffic jams, without taking into account that the road might at or near capacity (and you hit capacity in a hurry when you lose a lane).

My article doesn't account for variance in flow rates in congested traffic, but variance in car length (% of trucks on the road) might explain it. I'm not convinced that merging behavior is the culprit; the original article only speculates that that's the case. I'm putting forward a reasonable explanation for why that isn't the explanation, and a basis for evaluating whether it might be — in particular, whether a zipper merge results in higher flow rates after the bottleneck.

[rhizome]

Isn't variance in flow rate the crux of the issue? Merge lanes are a special case in traffic, where another flow is entering the channel. This creates turbulence around the merge point that does not exist where there is pure laminar flow and all lanes can be treated equally. Would it help if "simple cure" was renamed as a "simple improvement?"

[Arelius]

This.

Sure, there exists a point where the input flow is great enough that traffic must move slower. OP's entire argument is based off of this. The problem is that there are many things you can do to slow down the flow rate even further, and merging poorly creates this "turbulence" which wastes further flow.

And, it's clear that no improvement in merging behavior can beat the maximum road occupancy, however we can approach that limit much more closely.

I think that conceptually modelling traffic as fluid flows is quite clever, and the "turbulence" idea is particularly satisfying.

[jliszka]

FWIW I tried this out, seeing what happens when there are varying average car lengths on the road.

http://jliszka.github.io/assets/img/traffic/speed-vs-occupan... http://localhost:4000/assets/img/traffic/flow-vs-occupancy-2...

Also added as an update to the article.

[admax88q]

It also won't make you go slower. And rolling at a constant low speed is much less frustrating than constant stop and go traffic. Especially for people driving standard.

It's also more fuel efficient.

[kcorbitt]

I've always tried to smooth the wave on the fuel efficiency argument. I figure that maintaining a constant low speed has got to use less gas and be easier on my car than all the stopping and starting.

[danielweber]

I think lots of people, on both "sides" of this debate, have predetermined notions and are trying really hard to justify them.

[rdmcfee]

The initial point about rate of vehicles through a specific point per lane per hour couldn't be more simple and valid.

[cwoods]

Agree 100%.

From the article:

>Suppose you’re on a 2-lane (each way) highway and one lane is closed up ahead due to construction. Now the flow rate of your lane is cut in half (or there are twice as many cars in line in front of you, depending on how you want to look at it).

What I observe is that the speed is reduced to one twentieth of the speed, not just half. This is because people are merging very slowly while jostling resulting in needless braking. If everyone could agree upon a proper zipper merge, the speed for everyone would go up many times.

Or imagine a traffic signal at the merge point that only lets one lane go through for a minute each. The overall flow rate would be much higher than what it is without such a signal.

Discounting this based on theoretical flow rate (as if removing one lane reduces real traffic flow by only 50%) shows that the author totally ignores real traffic scenarios completely at odds with the title of the article.

[rdmcfee]

I think you're may be thinking of this as one mechanism instead of two separate mechanisms.

You are dealing with a queue as well as a through-rate at the merge-point. The through-rate with one lane can still be 1/2 of the through-rate with two lanes, but because you have a queue waiting to reach the merge-point you can end up waiting much longer. More spacious merging will not change this because of the principle stated in the first paragraph of the article.

Increasing the speed at the merge-point will not decrease the queue. It will only decrease the density of the queue but move it back further in traffic. Your time to cross the merge-point will be basically the same.

[cwoods]

>Increasing the speed at the merge-point will not decrease the queue. It will only decrease the density of the queue but move it back further in traffic. Your time to cross the merge-point will be basically the same.

I have to disagree with this. If you increase the speed at the merge point, someone who is newly joining the queue will definitely cross the merge point in lesser time than with lesser speed at the merge point.

[mavhc]

That doesn't matter though, as if they're going faster they're more spaced out. Only 2000 cars per hour can pass the merge point

[msandford]

Sure, but when traffic jams happen you often see not just ONE lane of traffic slowing down at the merge point but ALL lanes of traffic slowing down. On a four lane freeway narrowing to three lanes it's not the case that the two right lanes are stop & go and the two left lanes are 80MPH. EVERYONE slows to 10MPH. Furthermore the notion that you'll get 2000 cars per hour at the merge point irrespective of speed is ludicrous. Once everything slows down people act really douchey and don't let each other merge, etc.

I have witnessed eight lanes of traffic slow from 70MPH to 10MPH over a single poorly designed merge when there was more than enough aggregate free space for the merge. That happened because drivers don't accelerate hard enough on onramps and people don't redistribute themselves prior to shitty merges.

Show me a society that has no traffic jams and I'll show you one that's ready for socialism. Or vice versa.

[rdmcfee]

It's not about velocity it's about rate of cars through a point per hour. If you have a mergepoint with 10 lanes. Each lane can support say 20 cars per minute. If you have 200 cars approaching the merge-point per minute the cars can travel effectively at the speed of their choice.

If you close one lane, reducing the capacity of the mergepoint to 180 cars per minute while 200 cars are approaching a queue will build. The speed with which the cars mass the mergepoint is not relevant because the rate of cars per lane per minute will stay basically at 20 cars/lane/min.

As to your point about all lanes slowing down - cars will always redistribute as you can imagine. People tend to merge left as there's an additional traffic stream merging on their right. The writer made points about the capacity of the mergepoint vs. the cars approaching- not individual lanes and speeds.