Thanks for the remarks, Jakob.
The first remark confirmed that all of the tls are based on assumptions and that they can be recreated using (modified) assumptions through a delete and create sequence. The corresponding buttons have become meaningful yet.
The program id is still not understood. For example: I expected from the test example, that the template in input_additional.add.xml is used at any junction to create the new instance when I delete&create (I tested it by modifying the "template" file. Probably the documentation suffers somewhat because of the so called curse of knowledge (this is just a generic remark, no critique!). The only way to circumvent this is newbie feedback ;-).
A proper understanding is important especially as the attributs latestEnd and earliestEnd do not appear in netedit, and as such, a seperate additional file must be created.
I decided to postpone this topic. The discovery (in the docs) of a python script to compute tls offset times proved to improve the traffic flow quite substantially. Related to the next steps in my project this is adequate.
Rob
- If you do not want to modify phase durations manually to achieve fixed 120s cycles, you can set option 'tls.cycle.time' to 120 in the netedit options screen, then rebild the traffic lights in tls mode via delete,create
- each traffic light (tlLogic id) may have multiple programs and can switch between them at run time (i.e. day and night programs). The default programID is "0" but such a program is specific to one traffic light and you cannot reuse it (unless by copy-paste if the connection layout matches)
- to build an actuated traffic light with fixed cycle length you have to set attributes latestEnd and earliestEnd of the final green phase in the cycle to cycleTime - finalTransitionDuration (i.e. 117s if there is a final yellow phase before the cycle starts anew).
I'm coping with a city ring around the city center where all TLS have a fixed cycle time, as investigation (on location) showed me. As a first step, I changed the default status of all OSM-import related traffic lights to static (using a text editor, applied to osm.net.xml). At least that makes things simpler, and as such I also increased the phase times such, that the total cycle time does add to 120 instead of 90 seconds.
Yesterday - upon the investigation - I found that there is some variety in phase times. As such, actuated must be reactivated. However, cycle time remains constant at 120 ms. And the actuation should conform to that, e.g. using a fixed parameter setting.
The documentation (.../Simulation/Traffic_Lights.html#coordination) hints upon this as follows:
<tlLogic id="0" programID="my_program" offset="10" type="actuated">
<param key="coordinated" value="true"/> # should be important!
<param key="cycleTime" value="60"/> # here to insert: 120
<....
My specific questions:
lLogic id="0" while my net file shows up unique id's for every traffic light controlled junction. And programID="0" for all TLS'es. I'm quite a bit confused what these parameters exaclty mean, in the sense of e.g. using a certain program flow that is defined once and used in several traffic light locations.
Is it true that using coordination and cycleTime specification - any green prolonging from any edge would automatically result in a shorting of a perpendicular edge? In the real world case I see inductive loops only in the streets coming from outside the city ring, not on the ring itself. This would quite simply allow exactly that what I ask in this text paragraph.
Any suggestions highly appreciated.
_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
--
Dem Ingeniör ist nichts zu schwör (außer bei Force Majör)
