Re: [sumo-user] Traffic lights consideations: static/actuated related to OSM-based net
> 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 (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 : > 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 (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 : > > - 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 : > >> 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: >> >> # should be important! >> # 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
Re: [sumo-user] Traffic lights consideations: static/actuated related to OSM-based net
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 (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 : - 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 : 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: # should be important! # 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
Re: [sumo-user] Traffic lights consideations: static/actuated related to OSM-based net
- 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 : > 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: > > # should be important! > # 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 > ___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user