Prohibitions shown in Netedit differ from .net.xml response matrix

[m-kro]

In the prohibition frame, Netedit shows some connections as prioritary over others which instead have a mutual conflict with others in the network file. The Netedit prohibition frame already checks for mutual conflicts but does not match this case for some reason.

Top approach (index 0 to 2):

• should have right of way over opposed left turn (index 5) as shown in Netedit
• matrix in the network file shows a mutual conflict (line for index 0): 1100100000

Tostmannplatz_Yield.net.xml.zip

[namdre]

possibly related the issue mentioned in the last comment of #3850
The solution is outlined in #4256

[m-kro]

After inspecting NBRequest, the example case seems to result from the way prohibitions are stored (edge-based instead of lane-based as suggested in the .net.xml matrix).

[namdre]

@m-kro Yes. This is also mentioned in the last comment of #3850. Some of the response and foe bits are only computed at the time of writing and are not stored in myForbids. The outlined solution in #4256 is to cache the computed bits for all lane-to-lane relationships (and then to use these bits in prohibition-mode).

In the example network, the mutual conflict is an artefact of the the invalid signal plan. The left turning vehicles must obviously yield to the straight-going traffic in their common phase but the reverse is not true.
In some situations, vehicles that are stuck on the intersection after their phase ends must get priority by other streams that would otherwise have right of way and this gives rise to mutual response bits. Due the peculiar signal plan in the example network, this type of situation is detected and thus the mutual response bits are set.