Given a network definition file I want to construct / provide additional info, to allow / forbid certain turns at network nodes.
I am unable to find the information required for implementing this.§12 in the book grazes the subject, so I understand it is somehow done by replacement of nodes by sub-nets. The referred publications also avoid a more explicit instruction.
thanks for hints
you'll need the lanes object for your purpose. It does anything for you regarding routing and the sub-graph. So, you do not have to create the sub-graph by yourself.
The lanes object is contained in any scenario (scenario.getLanes()) and can be filled with information. Every lane contains the information about the links and lanes it is leeding to.
To use them just set the parameter useLanes in the qsim module in the config to true.
You can find an example how to fill the lane information in the signal tutorials: Please have a look at the method createLanes in the class CreateSignalInputWithLanesExample.
If you prefer using input files, you can also define the path to your lanes file in the config (module network, parameter laneDefinitionsFile). A lanes files has to look like this.
Hope that helps. Please let me know, if anything is missing!Cheers, Theresa
thank you very much! Such a lanes file was just the thing I was looking for, but couldn't find any mention of its existence or xml schema.And as I just see, this lanes file is not in my local clone. I only got a population and network in the directory, useSignalInput/ is missing completely. Have to pull a new revision probably, as mine is origin/master dated to 2016-08-10... but github history says the directory should have been there already.
Anyways, I will go and do the administrative repo things first.
NOTE: the files are not contained in branch 0.8.x, which was my work-base
shouldn't this be included?
When trying to launch the signal example with matsim 0.8.1 and the extension zip for this version, an error appears saying something like:
"simendtimeinterpretation not part of valid parameters"
When running in nightly build, the problem looks like Unmaterialized config group: signalsystems
Ideally, I would need to call matsim from the command line with a suitable config.
you are right: I updated the signals tutorial last september. The 0.8.x release branched somewhere before... We are currently working on a new release. It will of course contain the files. For the time beeing you can either use the nightly build or copy the files/code from github.
The error "Unmaterialized config group: signalsystems" has to do with the signals module. As default MATSim does not contain signals, you have to add it yourself when you want to use it:
scenario.addScenarioElement(SignalsData.ELEMENT_NAME, new SignalsDataLoader(config).loadSignalsData());
(see for example the class RunSignalSystemsExample or VisualizeSignalScenario in the signals tutorial). The error occurs because you run a config that contains the module signalsystems, but you have not added this scenario element. As you probably do not want to use signals, you can just delete the signalsystems module from your config. Starting matsim from the command line should then work.
Lanes, as mentioned by Theresa, are one possibility to incorporate turn restrictions. Before there were lanes in MATSim, turn restrictions were modelled into the network, and I think this is what the book refers to with "replacement of nodes by sub-nets".
Take the following example network:
Assume, you want traffic from node (3) to node (2) only be able to go to node (4), but not node (1). Then, you would "expand" the intersection/node (2) as follows:
(3) || / \ (2a) (2b) _______(2c) (2e)_________(1)/ \ (4) \-------(2d) (2f)---------/
and then add connecting links between:
but no link between (2a) and (2c).
If U-turns should be allowed, one would need to add more links, e.g. from (2d) to (2c) etc.
This increases the network complexity quite a bit by adding a large number of nodes and links to the network if turn restrictions are added for a large number of intersections. Thus, lanes are probably the better and cleaner way to add turn restrictions for larger scenarios.
Thanks for this clarifying explanation.-the ascii-art is strong in this one... much appreciated
I suspected that I would have to do something like this, but lanes indeed do look like the more elegant solution.
The big advantage of lanes is that routing still takes place on the original network, i.e. it saves a lot of computation time compared to this expanding-nodes approach.