Hello, the desired right-of-way behavior can be enabled by setting netconvert option --check-lane-foes.all The default behavior accounts for the fact that vehicles from the main direction are free to change lanes at will and are not obligated to account for merging vehicles from the side road. Note, that the lane-level conflict checks are always active for roundabouts (vehicles can freely enter on an outer lane even though the inner lane is busy) but this is usually accompanied by lane-changing restrictions within the roundabout ahead of the entries.
regards, Jakob Am Do., 16. Jan. 2020 um 21:09 Uhr schrieb Richard Tasgal <[email protected] >: > I think that the third suggestion, setting pass=true for certain > connections may work for my purposes. I'll try it. Thanks! (The first two > suggestions are unsuitable for my model.) In the analytic model, these > connections should not conflict; I hope there is no calculated conflict > hiding elsewhere that will produce errors. > > I'm going to ask a little more now anyway. Perhaps narrowing down the > scope of my question will suggest additional answers. The changes I think I > need to make are limited. I do not need to change arbitrary elements in the > right of way matrix. > > My problem is that it seems that some lanes of traffic are waiting > unnecessarily for other non-conflicting (though adjacent) lanes of traffic > in the intersection to clear. For example, in the attached figure, lane 1 > (the left of two lanes) in the road coming from the left is only allowed to > turn left, and only into lane 3 (the leftmost of four lanes) in the road > that exits to the top. No other lanes of traffic are allowed to go to the > same lane, so there should be no conflicts. (There are other conflicts in > other lanes due to merging, though not due to crossing lanes.) > Nevertheless, vehicles wait there. It seems to me that the vehicles afraid > of collisions with vehicles going into lane 2 of the road that exits to the > top. My hypothesis is there are undesired calculated foe lanes (if I have > the terminology correct) for lanes which merely neighbor but do not touch. > > Rich > > > > On Thu, Jan 16, 2020 at 9:06 PM Jakob Erdmann <[email protected]> > wrote: > >> Hello, >> editing right-of-way in an arbitrary manner is not supported at the >> moment. Here is what you can do: >> - in netedit there is right-of-way mode (hotkey 'w') for inspecting >> right-of-way. Editing is planned for the future >> - in inspect mode you can edit edge priorities to influence right-of-way >> generation (roads with higher priority get right of way) >> - in inspect mode you can override right-of-way for individual >> connections by setting attribute pass=true. This can be used to invert the >> right-of-way relationship with conflicting connections. However, if you set >> pass=true for two conflicting connections you will get an unregulated >> conflict (vehicles ignore each other) >> >> Editing the right-of-way matrix in the .net.xml is not recommended. You >> also have to change the connections states 'm', 'M' etc to match and you >> may get problems with internal junctions (there are some subtle >> interdependencies). >> >> regards, >> Jakob >> >> Am Do., 16. Jan. 2020 um 16:30 Uhr schrieb Richard Tasgal < >> [email protected]>: >> >>> It's possible that the right of way matrices at intersections are not >>> coming out the way I need them to be for my model (which may or may not >>> agree with reality most closely). >>> >>> I can see what I think are the relevant lines in the network files. I'll >>> give an example below. However, I don't know how to inspect them in >>> NetEdit, and I have not found instructions for programming them in the >>> plain XML files. Is editing the network file my only option? >>> >>> Rich Tasgal >>> >>> >>> <junction id="NodeX6Y4" type="priority" x="1200.00" y="400.00" >>> incLanes="NodeX7Y4toNodeX6Y4_0 NodeX7Y4toNodeX6Y4_1 NodeX6Y3toNodeX6Y4_0 >>> NodeX6Y3toNodeX6Y4_1 NodeX6Y3toNodeX6Y4_2 NodeX6Y3toNodeX6Y4_3 >>> NodeX5Y4toNodeX6Y4_0 NodeX5Y4toNodeX6Y4_1" intLanes=":NodeX6Y4_0_0 >>> :NodeX6Y4_1_0 :NodeX6Y4_2_0 :NodeX6Y4_3_0 :NodeX6Y4_4_0 :NodeX6Y4_4_1 >>> :NodeX6Y4_6_0 :NodeX6Y4_7_0 :NodeX6Y4_8_0 :NodeX6Y4_9_0" >>> shape="1193.60,412.00 1206.40,412.00 1206.84,408.89 1207.40,407.80 >>> 1208.18,407.02 1209.18,406.56 1210.40,406.40 1210.40,393.60 1208.18,392.98 >>> 1207.40,392.20 1206.84,391.11 1206.51,389.71 1206.40,388.00 1193.60,388.00 >>> 1193.16,390.22 1192.60,391.00 1191.82,391.56 1190.82,391.89 1189.60,392.00 >>> 1189.60,408.00 1191.82,408.44 1192.60,409.00 1193.16,409.78 1193.49,410.78"> >>> <request index="0" response="0000110000" foes="0000110000" >>> cont="0"/> >>> <request index="1" response="0000110000" foes="0000110000" >>> cont="0"/> >>> <request index="2" response="0000000000" foes="0000000000" >>> cont="0"/> >>> <request index="3" response="0000000000" foes="0000000000" >>> cont="0"/> >>> <request index="4" response="0000000000" foes="1100000011" >>> cont="0"/> >>> <request index="5" response="0000000000" foes="1100000011" >>> cont="0"/> >>> <request index="6" response="0000000000" foes="0000000000" >>> cont="0"/> >>> <request index="7" response="0000000000" foes="0000000000" >>> cont="0"/> >>> <request index="8" response="0000110000" foes="0000110000" >>> cont="0"/> >>> <request index="9" response="0000110000" foes="0000110000" >>> cont="0"/> >>> </junction> >>> >>> _______________________________________________ > sumo-user mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/sumo-user >
_______________________________________________ sumo-user mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
