Actuated signals (WIP) #298
Conversation
There is some temporary overlap in responsibility because the Adaptive phase type requires knowledge of the intersection state for its waiting list, and I don't want to bring that into the new traffic signal logic. Trying to respect Law of Demeter with the new code. There may be something that approximates this closely enough so I can take handling the Adaptive phase into the responsibility of the traffic_signals module without needing this extra information.
|
Something that may simplify your life -- |
…ls, in preparation to introduce Phase
|
Whoops. It looks like I tagged the wrong PR in my commit, so this got incorrectly closed.
Can you reopen this one @dabreegster? (And close #307)
…
|
|
Hah wow, weird that a PR can close another PR and not just an issue. Always been a bit confused that they share namespaces. |
|
I'm closing this PR, since @BruceBrown has implemented variable stages that pretty much capture all of this behavior. But thanks so much for working on this, and please reopen if there's any future work you have in mind. |
Work in progress -- not ready for review
To Do
TurnGroupMovement rather than hard-coded time at draw time.stage.protected_groupsin anticipation ofPhase. Replace usage ofstage.protected_groups.iter()with aget_protected_groupsmethod that returns an iterator.Phaseas collection ofMovement, which for now just has oneMovement. Forget_protected_groups, chain together theMovementiterators of eachPhase.SignalViewwhich provides an immutable view of the TrafficSignal/TrafficSignalState for clients like other actors and for drawing.PhaseTypeif no longer useful.