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

Netedit cannot load joined TLS via menu #4622

Closed
ZoltanBaksa opened this issue Sep 20, 2018 · 10 comments

Comments

@ZoltanBaksa
Copy link

commented Sep 20, 2018

In our Stuttgart-simulation project we have a basic map with netedit defined TLS programs. In the map the tls controlled junctions are not joined, only tls joined, where the TL attribute is set accordingly. There is a separate tll additional file where some important tls joins are having their own program sets and wauts. When the separate tll additional file is set in the sumo configuration file, it is working perfectly in sumo and sumo-gui, but netedit is not able to use it, because it cannot match the junctions to the waut-juncitons.

Technical explanation:

  • TLSEditorFrame implements it's own handler. This handler is not smart enough to deal with joined traffic lights.
  • NIXMLTrafficLightsHandler is smart enough put parses the definitions directly into NBTrafficLightLogicCont without the possibility for user intervention as implemented in GNETLSEditorFrame::TLSFile::checkTLSValids()
  • The solution is to use NIXMLTrafficLightsHandler with a temporary instance of NBTrafficLightLogicCont within TLSEditorFrame
@namdre

This comment has been minimized.

Copy link
Contributor

commented Sep 20, 2018

so to rephrase this: Your issue is that netedit does not handle WAUT. correct?

@ZoltanBaksa

This comment has been minimized.

Copy link
Author

commented Sep 20, 2018

Not exactly. The matching of waut's junctionID attribute works in sumo and sumo-gui, but not at all in netedit. The TL name information is stored in the connection definitions as reference to tlLogic tag's id attribute, not on the level of junction definition where only the type is set to 'traffic_light'. It would be more accurate, if the wautJunction tag would reference the tlLogic tag instead of the junction

@namdre

This comment has been minimized.

Copy link
Contributor

commented Sep 20, 2018

Despite the attribute name 'junctionID' the attribute actually references a tlLogic id so the implementation works as intended, only the attribute name is crap.

Netedit doesn't know anything about WAUT and doesn't even try to parse them.
However, loading the signal plans themselves should work. (Menu File->Traffic Lights->Load TLS Programs)

@ZoltanBaksa

This comment has been minimized.

Copy link
Author

commented Sep 20, 2018

That is what does not work, because netedit drops an error entry: 'ERROR, Junction doesn't exist', and the programs in traffic light editor remain the original.

@namdre

This comment has been minimized.

Copy link
Contributor

commented Sep 20, 2018

please send the input files directly to me so I can take a look.

@namdre namdre self-assigned this Sep 20, 2018
@namdre

This comment has been minimized.

Copy link
Contributor

commented Sep 21, 2018

The initial error message does not originate with the WAUT. Rather, netedit cannot load joined traffic lights via menu.
As a workaround, you can load the definitions via
netedit -s net.net.xml -i tll.add.xml

Then the programs are loaded and work (as long as they have the correct state length).
The different programs can be selected in the tls editor frame and edited as required.
When saving the network, the additional definitions are embedded in the .net.xml file

When saving the tls definitions, all of them are written to a file but the WAUT are lost. (#4631)
A simple solution would be to keep all the WAUT stuff in a seperate file.

@namdre namdre changed the title Importing separate tll file in Netedit doesn't work, with SUMO or SUMO-GUI does work Netedit cannot load joined TLS via menu Sep 21, 2018
@ZoltanBaksa

This comment has been minimized.

Copy link
Author

commented Sep 21, 2018

Thanks, till there is a bugfix I'll do so.

@namdre namdre closed this in 3dfc118 Sep 21, 2018
namdre added a commit that referenced this issue Sep 25, 2018
namdre added a commit that referenced this issue Sep 25, 2018
@ZoltanBaksa

This comment has been minimized.

Copy link
Author

commented Oct 3, 2018

Hello Jakob
I have tried the workaround, but the result was following
I loaded the separated programs, I could select and check the different programs, but when I made any change on one specific program (not default 0) of one joined TLS, I was not able to safe all TLS programs with the "Save TLS Program" button in the TLS editor window, because the saved file contained only the default program 0 of the changed TLS. The "File\Traffic Lights\Save TLS Programs" or "File\Traffic Lights\Save TLS Programs as" menu option stores all tls programs correctly

@namdre

This comment has been minimized.

Copy link
Contributor

commented Oct 3, 2018

@ZoltanBaksa Have you tried this with the latest development version?

@ZoltanBaksa

This comment has been minimized.

Copy link
Author

commented Oct 3, 2018

No, I used SUMO version: 1.0.1 + 0019-83bdcaf4ad

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