Scenario Manager in Vissim and Viswalk – Part II.1

Pedestrians, Fundamentals, Evaluations, Tipps and Tricks

If you have read the previous article on Scenario Management: one of the key features for traffic simulation you already know the basics about scenario management in Vissim and Viswalk. This initial article is continued with a whole series of articles on scenario management during this summer. We begin with some considerations on the precise nature of modifications.

Modifications take the Role of Patches

To get from scenario management what you expect to get, it is essential to have an idea of what Vissim does for you. This is mostly a matter of understanding the role and function of modifications from which scenarios are being built.

Dummy Model — dummy model for demonstration purpose. The magenta obstacle in the middle serves as anchor to better understand what happens with the areas (green),

It was briefly mentioned in blog post part I on scenario management: Modifications contain the result of an operation, but they are NOT operators. They are no scripts, no macro recordings, no recorded mouse gestures in the network editor. Rather think of modifications as patches. Patches are fixed on top of an existing base structure. They may extend the base structure and they may hide a part of it and present instead themselves. Having this – precise – idea of the role of modifications is important to expect the correct result when two or more modifications are combined for a scenario. Take for example the following base network which is deliberately kept simple with one obstacle and two areas:

For this, three modifications have been defined which all change the coordinates of the two areas:

Translation
Rotation
Change of shape

Three independent Modifications — Three Modifications: translation, rotation, change of shape.

In the project structure dialogue this looks like this:

These modifications can be combined to form scenarios.

Project Structure Scenarios — Project Structure: Scenarios

Unsurprisingly, those scenarios which comprise exactly one modification look as expected (and identical like the modifications):

One Modification per Scenario gives the expected result.

But what for the three scenarios which are made up of combinations of two scenarios?

Two Modifications per Scenario does not add effects when there are conflicts, but effectively results in ignoring all but the last change.

The scenario which combines translation and rotation in effect only has rotation applied. The scenarios which combine rotation or translation with a change of the shapes only have the latter applied.

This is not because in each case one of the two modifications was ignored, but because the coordinates of the areas are changed twice to new absolute values and the second change overwrites and erases the first.

Modifications are saved in .trax (model transfer) files and these contain elements of .inpx (model) files and no additional elements, particularly no mouse pointer gestures (e.g. “rotate”, “translate”, “duplicate”); it is not a macro recorder, nor a script file. The “language” of modifications is the same as the language of the model.

So, how is it decided which of the two modifications gets applied in either case? The simple answer is: the one which is loaded last (and thereby potentially supersedes all changes applied by previously loaded modifications) and the useful answer is: the one with the highest load index value. For example, if the Load Index values of the first and third Modification are exchanged…

… then the scenarios which are comprised of two modifications change accordingly: