search

a-b-street / abstreet

Transportation planning and traffic simulation software for creating cities friendlier to walking, biking, and public transit
https://a-b-street.github.io/docs/
Apache License 2.0
7.65k stars 340 forks source link

Some optional turns don't make sense #327

Open belt-drive opened 4 years ago

belt-drive commented 4 years ago

Not sure if this qualifies as a bug, but reporting it here. I've been away for a while, so I apologize if this has already been discussed elsewhere.

It seems like it's possible to allow all optional turns at an intersection on every stage of a light cycle. Meaning, if there's a cycle in which left turns have priority, I can still turn on going straight through the intersection in the opposite direction as an "optional turn." This is a recipe for disaster in reality, but not when dealing with perfectly safe automatons in a simulation. The upshot is that it seems like there's no penalty to turning on all kinds of dangerous, unrealistic "optional turns" and "optional straights." In essence, every intersection becomes a strange version of a stop sign where the traffic signals just indicate who has priority and when pedestrians can walk or not. I've been able to increase throughput at some intersections dramatically by collapsing multiple phases of a light cycle into two or three "superphases" with all optional turns enabled and then adding an all-walk stage at the end. This has no basis in reality, as far as I can tell, but it works in the game.

dabreegster commented 4 years ago

This is definitely a bug, but I'm not sure how to decide what movements are safe to attempt after yielding. Maybe "straight" turns that conflict with others shouldn't be allowed at all, but right-turn yields are OK if they don't cross an entire other road, and left-turn yields from roads that have a protected straight turn are OK.

When the "superphase" approach works in-game, that's an indication that a stop sign might work better there, at least for the moment in the game. There's an option in the signal editor to convert to one. Of course this probably doesn't match reality well; the poor performance is likely related to improper signal timing across a corridor, all of the bugs causing gridlock, etc.

An extreme example of this:

Screenshot from 2020-09-14 10-33-21

belt-drive commented 4 years ago

You mentioned stop signs. I agree with you that a "superphase" is similar to a stop sign, with one key difference: pedestrian control. Without pedestrian control, some stop signs become functionally blocked due to continuous pedestrian traffic, causing gridlock. I spend all of my time in the game on the South Seattle map, which includes portions of downtown Seattle, and I've found that I need signals primarily to control pedestrians and to a lesser extent to decide which vehicular direction gets priority. It's similar to using a traffic signal to simulate a beg button to limit the amount of time that pedestrians can cross. So I guess it's kind of like a stop sign for vehicles with beg buttons for pedestrians?

On Mon, Sep 14, 2020 at 10:38 AM Dustin Carlino notifications@github.com wrote:

This is definitely a bug, but I'm not sure how to decide what movements are safe to attempt after yielding. Maybe "straight" turns that conflict with others shouldn't be allowed at all, but right-turn yields are OK if they don't cross an entire other road, and left-turn yields from roads that have a protected straight turn are OK.

When the "superphase" approach works in-game, that's an indication that a stop sign might work better there, at least for the moment in the game. There's an option in the signal editor to convert to one. Of course this probably doesn't match reality well; the poor performance is likely related to improper signal timing across a corridor, all of the bugs causing gridlock, etc.

An extreme example of this:

[image: Screenshot from 2020-09-14 10-33-21] https://user-images.githubusercontent.com/1664407/93118830-b8c8df00-f675-11ea-91eb-8977b4f67f99.png

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/dabreegster/abstreet/issues/327#issuecomment-692206459, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQEDTNFTZBDON4ZNBCPYJNLSFZIJZANCNFSM4RLXXJKA .

dabreegster commented 4 years ago

Ah, the difference makes more sense. I think you've hit upon a few more issues:

1) There are many crosswalks in the game that don't exist in reality. This is partly due to no adequate data source in OpenStreetMap or Seattle Open Data for crosswalks. But also partly because there are many canonical places where pedestrians cross without any explicit markings on the ground in reality. I've seen gridlock form around 23rd and Madison because of inopportune pedestrian crossings. Some of the crossings aren't reasonably possible/common in real life.

2) At stop-sign controlled intersections, pedestrians hop onto the crosswalk and start blocking cars pretty quickly. In reality, if the movement crosses an arterial from a minor road (like crossing MLK east/west on Howell), cars aren't going to stop. So there, it'd be much more realistic for the movement to still be possible (even without an explicit crosswalk), but low priority, only happening when there's a sufficient break in traffic.

The superphase + all-walk stage is an interesting short-term workaround, but the goal of the game is to mimic reality well enough so that proposals in-game stand some chance of applying to reality. I haven't made much headway on all of the gridlock issues yet, but it's extremely useful to surface more issues like unrealistic pedestrian priority. I'll keep trying to whittle down all the root causes.

(The small bit of progress: easier automated measurement. I have a script that tries to run 12 hours of a map, cancelling some percentage of all trips. For south seattle, I found that cancelling 60% of all trips seems to work, but 50% melts down. So we're still quite far from fixing all of the problems.)

belt-drive commented 4 years ago

This makes sense, thank you for the explanation. A few more observations:

1) To be a complete superphaseist, I now add an all-walk stage at the end and then add back in all optional turns to that all-walk phase. So, it's superphase all the time! Just shifting priority from cars to peds for some amount of time. 2) While I said before that there's essentially no reason not to enable all optional turns all the time, I found out that there is one drawback: drivers in the game don't follow priority ordering very well! I've found that priority left turns sometimes get overridden by cars going straight that are supposed to be yielding. 3) I was thinking about this issue in relation to pedestrian and driver behavior in reality. Sometimes people build up in clusters before crossing en mass, especially on busy streets as you mentioned. There's also the "waving effect", where sometimes a pedestrian will yield to a car and "wave" them through if they've seen that the car has already been waiting for one or two pedestrians.

More broadly on 3), I think one upshot of AB Streets might be, in part, to prove the vital importance of human flexibility in making our road system function. Maybe the game is an accurate representation of reality in that respect.

On Mon, Sep 14, 2020 at 3:02 PM Dustin Carlino notifications@github.com wrote:

Ah, the difference makes more sense. I think you've hit upon a few more issues:

1.

There are many crosswalks in the game that don't exist in reality. This is partly due to no adequate data source in OpenStreetMap or Seattle Open Data for crosswalks. But also partly because there are many canonical places where pedestrians cross without any explicit markings on the ground in reality. I've seen gridlock form around 23rd and Madison because of inopportune pedestrian crossings. Some of the crossings aren't reasonably possible/common in real life. 2.

At stop-sign controlled intersections, pedestrians hop onto the crosswalk and start blocking cars pretty quickly. In reality, if the movement crosses an arterial from a minor road (like crossing MLK east/west on Howell), cars aren't going to stop. So there, it'd be much more realistic for the movement to still be possible (even without an explicit crosswalk), but low priority, only happening when there's a sufficient break in traffic.

The superphase + all-walk stage is an interesting short-term workaround, but the goal of the game is to mimic reality well enough so that proposals in-game stand some chance of applying to reality. I haven't made much headway on all of the gridlock issues yet, but it's extremely useful to surface more issues like unrealistic pedestrian priority. I'll keep trying to whittle down all the root causes.

(The small bit of progress: easier automated measurement. I have a script that tries to run 12 hours of a map, cancelling some percentage of all trips. For south seattle, I found that cancelling 60% of all trips seems to work, but 50% melts down. So we're still quite far from fixing all of the problems.)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/dabreegster/abstreet/issues/327#issuecomment-692337489, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQEDTNFCQ2W5VJ2QMXX2VLLSF2HHDANCNFSM4RLXXJKA .