Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add new mode for editing right of way at priority junctions #3850

Open
namdre opened this issue Feb 27, 2018 · 9 comments

Comments

@namdre
Copy link
Contributor

commented Feb 27, 2018

  • hotkey 'w'
  • similar to connection mode:
  • when entering mode, enable show-connections
  • color legend as described below
  • first click selects a connection
    • connections that intersect are highlighted:
    • dark green for those which yield to the selected
    • red for those with priority over the selected
  • second click on any intersecting connection toggles right-of-way
  • buttons ok/cancel
  • button 'reset' (resets to default right of way)

Currently, right-of-way can only be configured via xml inputs with a mix of

  • edge priority
  • connection attribute 'pass'
  • prohibitions

It is probably not possible to map arbitrary right of way rules to the above 3 mechanisms. In that case, there would need to be extensions to the plain-xml format and to the way right-of-way logic is handled in NBRequest.

The first step is to lay the netconvert groundwork (Jakob)
The second step is to implement the new mode in netedit (Pablo)

  • default colors when no connection is clicked for a tls junction should not conflict with the mode specific connection colors
@namdre

This comment has been minimized.

Copy link
Contributor Author

commented Feb 27, 2018

@palvarezlopez This is not urgent. I'm just putting in here to get it out of my head.

@m-kro

This comment has been minimized.

Copy link
Contributor

commented Jun 11, 2018

I would second this prohibition mode. Sometimes, the guessed yielding is just not what you want. I started coding on a prohibition mode before watching the issue list. For now, it consists only of the color legend as described above (see screenshot):
prohibitionmode
Is there a way to collaborate and speed up this topic?

@namdre

This comment has been minimized.

Copy link
Contributor Author

commented Jun 11, 2018

I think making the right of way rules visible is good first step and a worthwhile feature all by itself.
If you send a pull request that adds this mode i'll be happy to review and merge it.
The next step is to figure out to which extent the internal structures and the xml input formats need to be extended.
For that it would help if you could provide a few examples where the default right of way rules are incorrect (the original .net.xml file and a snippet of the element as you would prefer it to be).

namdre added a commit that referenced this issue Jun 18, 2018
namdre added a commit that referenced this issue Jun 18, 2018
namdre added a commit that referenced this issue Jun 18, 2018
@namdre

This comment has been minimized.

Copy link
Contributor Author

commented Jun 20, 2018

refinements are need because the currently used methods
node->foes() and node->forbids() do not always reflect the final state of the junctionLogic (see the additional checks in NBRequest::getResponseString and NBRequest::getFoesString).

Furthermore the methods would currently retrieve invalid results for lefthand networks due to the way they are computed (via mirroring twice). A possible solution would be to use the cached logic matrix that is proposed as a fix for #4256

@namdre

This comment has been minimized.

Copy link
Contributor Author

commented Nov 29, 2018

  • Right of way mode is now consistent with .net.xml
  • Right of way can be customized in detail by setting rightOfWay=edgePriority and then customizing edgePriorities.

@m-kro can you please check whether there are use-cases that you still cannot model with the new capabilities?

@m-kro

This comment has been minimized.

Copy link
Contributor

commented Dec 3, 2018

Using the edge priorities gives me strange results. I used the same network excerpt as in the screenshot above.
Using the highest numbers for the main incoming and outgoing edges (top>bottom) still results in mutual conflicts with left-turn bottom>left but also with connections coming from left. The said left turn is not signalized as the traffic light is split across multiple nodes.

@namdre

This comment has been minimized.

Copy link
Contributor Author

commented Dec 6, 2018

Can you attach the network?
Mutual conflicts are created to deal with vehicles stranded on the intersection when their phase ends (the phase that has green afterwards still needs to let such vehicles exit safely).
Is the signal plan for that traffic light the one that will also be used in the simulation? If the signal plan is invalid, the mutual conflicts may be invalid as well.

@m-kro

This comment has been minimized.

Copy link
Contributor

commented Jan 8, 2019

Tostmannplatz_Nullfall.net.xml.zip

grafik
The screenshot shows the attached intersection whose priority settings have been calculated with the priority attribute. Look at the car turning right just next to the western crossing. There is no pedestrian anywhere, but it just does not leave. After a while, this will block the intersection...

@namdre

This comment has been minimized.

Copy link
Contributor Author

commented Jan 16, 2019

was caused by #5047

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.