-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Model validity (base case) #8
Comments
Added traffic from outside the city in 3a951f1, 4dfb7a3 and 1639c64. There's definitely traffic now. This is with What we're basically doing is assuming the amount of current traffic between the red and blue areas, as based on V-MRDH 3.0, distributed over the day based on ODiN. With 0.75 is close enough to see some real effects. The big problem is the internal mode choice now:
So let's introduce a "comfort factor" with some negative values for bikes and positive for cars. It applies directly on the perceived costs. CC @quaquel |
This looks good. Now a slightly evil question that you should not think about too long: how plausible is this 0.75 number? |
Implementing a comfort factor was completely trivial (428b2fb). Wasn't that happy about the state of my codebase, but this is a nice testament to it. Simulation time is though the roof with that many cars.
Ï think the better question are:
The fact that 0.75 (now also testing 0.6) is within the right order of magnitude (and even withing a 2x range) I'm actually surprised about. |
So, how should I read this number: does it mean that 76% of the traffic comes from outside the red area? |
No, sorry it's something else: It's just a scalar that scales the numbers from the existing OD-matrices by some factor. So 1 means exactly those numbers. It's a multiplier for external traffic. The ratio between internal and external traffic is an interesting number to keep in check, since internal is adapting but external is static. |
One small issue I still had is that we didn't allow trips within the same MRDH65 area. Within some areas, this number is really big. This caused a major overrepresentation in trips to areas further away, increasing the average distance and travel time spend. This had two effects on model validity:
The resolution bump for bike/transit travel time and distance lookups from mrdh65 to pc4 resolution in 96f826e allowed for trips within mrdh65 regions to take place, as long as there is more than one PC4 area in that MRDH65 (there isn't a travel time to travel to your own PC4 area. That was the case for all MRDH65 regions except three:
0a501be updated the destination lookups to only exclude identical MRDH65 regions if they had only one PC4 region, instead of all identical MRDH65 regions. So this now allows trips to take place within the remaining 18 MRDH65 regions, which is often done: ~202 of ~378 thousand trips are taken within the same mrdh65 region (~53.5%). This corrects the bias described above, and makes the model more accurate and representative for how people actually travel. @quaquel coming back to your question on |
This is a major shift in behavior, as expected: First of all, it can be seen that journeys cover shorter distances and also take way less time: In the bottom row (with the new behavior) the graphs are skewed way more to the left. Cost and perceived cost follow the same patterns. First thing to notice is a significant decrease in transit rides. Which is plausible, since those are often more suitable for bike or car rides. Bike use has increased in general, but since the network is less busy, the dip in car used around peak times disappeared. The travel speed remains high and vehicles remaining in each area simultaneously is lower. The per-area heatmaps also show that areas like Rotterdam Centrum and Rotterdam Alexander, which were at peak congestion, are now a lot less congested: Let's try seeing what raising back the |
There are a few "problems" with the model that ideally should be addressed. Either this happens in this research, or is documented properly as a limitation.
1. Mode choice behavior
Model behavior
Currently the mode choice distribution - in the base case, so without any AVs - looks like this:
Which shows that transit is preferred for the longer distances, while cycling is from the shorter ones.
And the numbers are as follows.
Note: The inner center includes the districts Noord, Kralingen, Rotterdam Centrum, Feyenoord, and Delfshaven. The 21 areas the whole area in the city polygon.
Validation data
As for validation data, we know the following:
In V-MRDH 3.0 data, the mode choice distribution should be as follows:
Based on ODiN 2023 (2022 looks the same):
Alignment:
Non-alignment:
Potential solutions
a. Increase the VoT
b. Add a fixed penalty for each trip
c. Add a distance penalty (possibly non-linear)
2. Lack of actual traffic jams
In general, the average speed stays very high, indicating a lack of traffic jams in the model (bottom left plot).
This could be caused by either/or:
It's difficult to find data on how slow traffic should be going in peak traffic, but certainly faster than this. TomTom Move might have this data (available).
Potential solutions:
Synthesis
The text was updated successfully, but these errors were encountered: