> The first remark confirmed that all of the tls are based on assumptions Please see https://sumo.dlr.de/docs/Simulation/Traffic_Lights.html#automatically_generated_tls-programs
> 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 ;-). Indeed, thank you for the feedback. The key misunderstanding seems to be that you expect the programs to work as templates whereas they are actually fully functional programs that apply to a single traffic light only. If you create a new traffic light, it is built from options and heuristics alone without considering any previously loaded programs. I'm still at a loss on how to turn this insight into a documentation improvement tough. Suggestions are welcome. regards, Jakob Am Fr., 4. Feb. 2022 um 18:57 Uhr schrieb Rob Maris <r...@maris-ee.eu>: > 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 > > > Am 03.02.2022, 23:42 Uhr, schrieb Jakob Erdmann <namdre.s...@gmail.com>: > > - 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). > see > https://sumo.dlr.de/extractTest.php?path=sumo/basic/tls/actuated/coordination/saturatedNS/fixedCycle_coordinated > and > https://sumo.dlr.de/extractTest.php?path=sumo/basic/tls/actuated/coordination/saturatedNS/fixedCycle_coordinated_offset > > > Am Do., 3. Feb. 2022 um 12:44 Uhr schrieb Rob Maris <r...@maris-ee.eu>: > >> 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@eclipse.org >> 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) > _______________________________________________ > sumo-user mailing list > sumo-user@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/sumo-user >
_______________________________________________ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
