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!
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!
Up next: why F = ma really, really matters for space launches. Experts don't know this!
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.
It utterly fails to explain the extreme variance in real traffic throughput during congestion. The original article does.
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.
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.
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.
It's also more fuel efficient.
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.
Probably all the people that passed around the critiqued link and suggested that it gives a way to improve traffic flow?
And that's why people pass around the link.
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.
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.
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.
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.
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.
1. If the flow rate changes with speed, thus merging at 5 mph instead of 50 is bad.
2. What will prevent accidents. I suggest start-stop traffic causes more accidents than free flow.
3. Fuel efficiency, which would depend on many things, eg the percentage of cars in traffic that stop their engines when the car is stopped.
So if the car is travelling at .5 carlengths per second then the duration per car should be 4 seconds whereas if the car was travelling at 10 carlengths per second the duration per car should be only 2.1 seconds.