|Re: [sumo-dev] Setting individual traffic light state via TraCI (follow up)|
a consideration regarding setting traffic light linkIndex attributes, and connections within intersections.
If I have an intersection, and have set all connections the way I need, and set linkIndices as appropriate, and afterwards split an edge connected to the junction, all indices (for all junctions controlled by this traffic light id) will be reset. Also (and probably that is why the indices are reset), the connections in the junction connected to the splitted edge are re-generated.
This means if one makes changes to the network, a lot of work has to be redone. Is this behaviour by design? Maybe it would be possible to choose wether or not to regenerate the connections? The same applies when joining junctions, though in that case it makes somewhat more sense that all is regnerated (though the option to join without altering existing data would be nice).
Kind regards, Menno
Op 14-12-2017 om 9:49 schreef Jakob Erdmann:
in the latest development version of sumo the following things are implemented:
- you can assign custom numerical values for each traffic-light controlled connection in netedit (inspect connections and set attribute linkIndex)
- multiple connections can share the same numerical value and thus form a group
- traffic light programs can be shortened to the number of used values (button 'cleanup states' in traffic light mode)
- these numerical values can be shown in netedit and sumo-gui (junction settings 'show link tls index')
- the command traci.trafficlight.setLinkStat
e sets the state for the given numerical value2017-12-12 10:48 GMT+01:00 Menno van der Woude <menno@xxxxxxxxxxxxxxxxxx <mailto:menno@codingconnected.
So the only thing that is missing is the capability to assign stringIDs for the numerical group ids. I'm reluctant to add string-aliases to the core data model of a connection because it is somewhat redundant. However, sumo supports key-value maps for storing non-core parameters and abitrary user data. These maps can be read and written via TraCI and are also shown in SUMO-GUI (The only thing currently missing is editing them in netedit).
For example traffic light parameters see http://sumo.dlr.de/wiki/Simula
I think adding a new parameter
<param key="alias" value="K1 K2 K3 K4"/>
that would map the alphanumerical Ids K1 to K4 onto the numerical group IDs 0 to 3 would be fine.
Things that would be needed:
1) in the gui, when selecting show link tls index, the alias should automatically be shown below the index value if it exists
2) in traci.trafficlight.setLlinkSta
te a non-numerical index should automatically be translated into the numerical ID using the alias parameter if it exists
3) in netedit, there should be a way to show and edit <param> values.
Points 1 and 2 should be very easy to do but 3) requires some thinking about UI design to make it fit nicely into the general architecture (many objects besides traffic lights can use <param>s). 3) is on our to-do list anway and would probably be done in the first quarter of 2018.
I guess if you mostly keep your signal plans in separate xml files or you set them via TraCI anyway then 3) is not urgently needed for your use case.
What kind of use do you anticipate?
eu>>:E menno@xxxxxxxxxxxxxxxxxx <mailto:menno@codingconnected.
a while ago I patched SUMO to allow me set state for individual
traffic lights via a Traci command (see the patch I sent on 23th
July 2017). This worked, but I still would like to implement it in a
more robust way, preferably:
- allow (via netedit) setting a property on a connection in an
intersection; not a unique ID, because sometimes multiple
connections will belong to group of lights controlled as a single
phase. So it would be a string property called "TrafficLightId" or
- add a Traci call that allows setting the trafficlight state for a
'single' traffic light, where a 'single' traffic light means all
connections that have a given value set for the "TrafficLightId"
This scenario would, at least in my case, make it much more easy to
control an intersection using Traci: I could thus easily set the
TrafficLightId values for all connections of an intersection, and
from my Traci client implementation, call a
SetSingleTrafficLightState function, using those (not unique) Id values.
This as opposed to the current situation, where I have to closely
look at the connections in Netedit, to determine their index in the
traffic light state string (e.g. "yyyGGrr"), and subsequently map
the traffic lights from my program to that indexed string.
The latter means much manual work and manually coding the named
mapping of lights to the string. It is also very sensitive for
mistakes. The former could be implemented in the Traci client in a
much more generic way.
What is your view on this? I would be happy to take time to
implement this, however, I wonder if this would be a feature that
could find its way back into the SUMO master branch? Otherwise it
would make little sense, as I would have rewind my changes onto the
master branch very often. If this is a welcome addition, I would
need some advice where to start with adding the named property to a
connection, and how to add a textbox to the UI of netedit for this.
Thanks, kind regards,
Menno van der Woude
CodingConnected e.U. (Wien - Österreich)
W www.codingconnected.eu <http://www.codingconnected.eu
sumo-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
sumo-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
Back to the top