Anda di halaman 1dari 810

PTV VISUM 13

FUNDAMENTALS

Copyright
2013 PTV AG, Karlsruhe, Germany
All brand or product names in this document are trademarks or registered trademarks of the
corresponding companies or organizations. All rights reserved.
Cover picture: VBZ

Legal agreements
The information contained in this documentation is subject to change without notice and
should not be construed as a commitment on the part of the vendor.
Without the prior written permission of PTV AG, this manual may neither be reproduced or
stored in a retrieval system, nor transmitted in any form or by any means, electronically,
mechanically, photocopying, recording, or otherwise, except for the buyer's personal use as
permitted under the terms of the copyright.

Warranty restriction
The content accuracy is not warranted. We are grateful for any information on errors.

Imprint
PTV AG
76131 Karlsruhe
Germany
Tel. +49 721 9651-300
Fax +49 721 9651-562
E-mail: info@vision.ptvgroup.com
www.ptvgroup.com
www.vision-traffic.ptvgroup.com
Last amended: May 28, 2013 EN-US F

Structure
1

Fundamentals of the program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Network model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Demand model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Impact models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

User model PrT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

User model PuT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429

Operator model PuT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521

Environmental impact model and HBEFA . . . . . . . . . . . . . . . . . . . . . . 651

Economic assessment according to EWS . . . . . . . . . . . . . . . . . . . . . . 663

10

GIS functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671

11

Interactive analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697

12

Tabular and graphical display. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725

Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
List of illustrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
List of tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787

PTV AG

Structure

II

PTV AG

Contents
1

Fundamentals of the program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1


1.1
1.2
1.3
1.4
1.5

Network model the transport supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2


Transport demand model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Impact models methods to calculate the impact of traffic . . . . . . . . . . . . . . . . . . 6
Analysis of results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Comparing and transferring networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5.1
1.5.2
1.5.3

1.6

Managing scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.6.1
1.6.2

Comparing version files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9


Network merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Model transfer files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Keywords: project, modification, scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Managing projects efficiently . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Network model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1

Network objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
2.1.6
2.1.7
2.1.8
2.1.9
2.1.10
2.1.11
2.1.12
2.1.13
2.1.14
2.1.15
2.1.16
2.1.17
2.1.18
2.1.19
2.1.20
2.1.21
2.1.22

2.2

34
37
40
45
46
46
48
51
52
52
54
56
57
57
70
72
74
75
76
77
78
84

Spatial and temporal correlations in Visum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84


2.2.1
2.2.2
2.2.3

PTV AG

Transport systems, modes and demand segments . . . . . . . . . . . . . . . . . . . . . .


Nodes and turns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OD pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Main nodes and main turns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Main zones and main OD pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Territories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Stop hierarchy: Stops, stop areas, stop points . . . . . . . . . . . . . . . . . . . . . . . . . .
PuT operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PuT vehicles: Vehicle units and vehicle combinations . . . . . . . . . . . . . . . . . . . .
The line hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Points of Interest (POI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Count locations and detectors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Toll systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GIS objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Screenlines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Junction modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Calendar and valid days . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84


Time reference of the demand (time series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Time reference of the volumes: Analysis time slots and projection. . . . . . . . . . . 88

III

Contents

2.2.4
2.2.5

2.3

Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94
2.3.1
2.3.2
2.3.3
2.3.4

2.4
2.5

Tables in the surface model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111


Multi-part surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Sharing points between surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Demand model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119


3.1

Demand objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119


3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.1.7

3.2

3.3

Matrices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Demand segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Time series. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Demand model structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Person groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Activities, activity pairs, activity chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Demand strata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Demand modeling procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125


3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.2.6

Standard 4-step model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126


EVA model for passenger demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Activity chain based model (tour-based model) . . . . . . . . . . . . . . . . . . . . . . . . . 161
Estimate gravitation parameters (KALIBRI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Gravity model calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Displaying and editing matrices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .184


3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3.3.6
3.3.7
3.3.8
3.3.9
3.3.10
3.3.11
3.3.12
3.3.13
3.3.14
3.3.15
3.3.16
3.3.17

IV

Direct attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Indirect attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
User-defined attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Time-varying attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Subnetwork generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107


The surface data model in Visum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
2.5.1
2.5.2
2.5.3

Temporal and spatial differentiation of calculation results . . . . . . . . . . . . . . . . . . 92


Adjustment of the capacities to the demand values . . . . . . . . . . . . . . . . . . . . . . . 93

Displaying matrices in tabular form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185


Displaying matrix values as a histogram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Comparing matrices graphically in pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Transpose, reflect upper or lower triangle, apply mean value . . . . . . . . . . . . . . 186
Copy, paste and apply diagonal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Round. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Form reciprocal, raise to power, take logarithm, exponential function . . . . . . . . 187
Maximum or minimum formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Make symmetrical: mean value upper / lower triangle . . . . . . . . . . . . . . . . . . . . 188
Calculate the combination of matrices and vectors . . . . . . . . . . . . . . . . . . . . . . 188
Defining matrices as formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Projection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Projection of aggregated areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Converting zone and main zone matrix into each other . . . . . . . . . . . . . . . . . . . 191
Extending matrices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Aggregating matrix objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Splitting (extending) matrix objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
PTV AG

Contents

3.4

Matrix correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195


3.4.1
3.4.2
3.4.3

Impact models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205


4.1

The types of impact models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205


4.1.1
4.1.2
4.1.3

4.2
4.3
4.4

The user model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205


The operator model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
The environmental impact model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Impedance functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207


Paths in PrT and PuT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Skims / indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
4.4.1
4.4.2

Updating demand matrix with TFlowFuzzy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195


Projecting PrT path volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Calibrating a PrT matrix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Skim matrices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209


Global indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

User model PrT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211


5.1
5.2
5.3
5.4

Overview of the PrT assignment procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 211


Example network for the PrT assignment procedures . . . . . . . . . . . . . . . . . . . . 213
PrT Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Impedance and VD functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
5.4.1
5.4.2
5.4.3
5.4.4

5.5

228
228
229
277

General notes on the blocking back model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293


Procedure of the blocking back model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

Convergence criteria of the assignment quality . . . . . . . . . . . . . . . . . . . . . . . . . 307


Distribution models in the assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
5.10.1
5.10.2
5.10.3
5.10.4
5.10.5
5.10.6

PTV AG

Impedance of turns from Turns VD function . . . . . . . . . . . . . . . . . . . . . . . . . . .


Impedance of turns from Nodes VD function . . . . . . . . . . . . . . . . . . . . . . . . . .
Intersection Capacity Analysis according to the Highway Capacity Manual (ICA) . .
Signal time optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

PrT skims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290


Distribution of the traffic demand to PrT connectors. . . . . . . . . . . . . . . . . . . . . . 291
Blocking back model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
5.8.1
5.8.2

5.9
5.10

216
218
224
225

Impedances at node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226


5.5.1
5.5.2
5.5.3
5.5.4

5.6
5.7
5.8

Impedance of a PrT route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Predefined VD functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of the calculation of the link impedance . . . . . . . . . . . . . . . . . . . . . . .
User-defined VD functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The Kirchhoff model in the assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


The Logit model in the assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Box-Cox model in the assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Lohse model in the assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lohse model with variable beta in the assignment . . . . . . . . . . . . . . . . . . . . . .
Comparison of the distribution models for the assignment . . . . . . . . . . . . . . . .

309
309
310
311
312
314

Contents

5.11

Incremental assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .315


5.11.1
5.11.2
5.11.3
5.11.4

5.12

Equilibrium assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .320


5.12.1
5.12.2
5.12.3
5.12.4
5.12.5

5.13

Evaluation of the stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365


Input and output attributes of the stochastic assignment . . . . . . . . . . . . . . . . . . 366
Procedure of the stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Similarity of routes and commonality factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Example for the stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

TRIBUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .376
5.17.1
5.17.2
5.17.3
5.17.4
5.17.5
5.17.6
5.17.7
5.17.8

VI

Fundamental principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354


Evaluation of the Assignment with ICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Input and output attributes of the assignment with ICA . . . . . . . . . . . . . . . . . . . 357
Procedure of the Assignment with ICA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
VD functions in assignments with ICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

Stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .365


5.16.1
5.16.2
5.16.3
5.16.4
5.16.5

5.17

Example of the Equilibrium_Lohse procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 346


Input and output attributes of the Equilibrium_Lohse procedure . . . . . . . . . . . . 350
Procedure of the Equilibrium_Lohse assignment . . . . . . . . . . . . . . . . . . . . . . . . 353
Evaluation of the Equilibrium_Lohse procedure . . . . . . . . . . . . . . . . . . . . . . . . . 354

Assignment with ICA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .354


5.15.1
5.15.2
5.15.3
5.15.4
5.15.5

5.16

Mathematical formulation and theoretical framework . . . . . . . . . . . . . . . . . . . . . 332


Local user equilibrium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Descent direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Assignment algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Input and output attributes of the equilibrium assignment (LUCE) . . . . . . . . . . . 342
Persistent storage of bushes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Start from an initial assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Optimizing the proportionality in the route distribution . . . . . . . . . . . . . . . . . . . . 344

Equilibrium_Lohse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .346
5.14.1
5.14.2
5.14.3
5.14.4

5.15

Evaluation of the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321


Introductive example for the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . 322
Input and output attributes of the equilibrium assignment . . . . . . . . . . . . . . . . . 324
Procedure of the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Calculation example for the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . 330

Linear User Cost Equilibrium (LUCE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .331


5.13.1
5.13.2
5.13.3
5.13.4
5.13.5
5.13.6
5.13.7
5.13.8

5.14

Example of the incremental assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316


Procedure of the incremental assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Input and output attributes of the incremental assignment. . . . . . . . . . . . . . . . . 318
Evaluation of the incremental assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

Input and output attributes of the TRIBUT procedure . . . . . . . . . . . . . . . . . . . . 376


Basics of the assignment with toll consideration . . . . . . . . . . . . . . . . . . . . . . . . 378
LogN distribution of the random variable VT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .383
Route search - efficient frontier as exclusive criterion . . . . . . . . . . . . . . . . . . . . 385
Route split . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Route balancing in the equilibrium iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Route distribution in the iteration of the TRIBUT Equilibrium_Lohse . . . . . . . . . 387
List outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388

PTV AG

Contents

5.18

Dynamic User Equilibrium (DUE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389


5.18.1
5.18.2
5.18.3
5.18.4
5.18.5
5.18.6
5.18.7
5.18.8
5.18.9

5.19

389
390
393
397
406
408
410
412
418

Dynamic stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419


5.19.1
5.19.2
5.19.3

5.20
5.21

Fields of application of the Dynamic User Equilibrium procedure . . . . . . . . . . .


Overview of the dynamic equilibrium assignment model . . . . . . . . . . . . . . . . .
Mathematical framework of the Dynamic User Equilibrium. . . . . . . . . . . . . . . .
Network performance model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Assignment of the network demand (network loading) . . . . . . . . . . . . . . . . . . .
The overall model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of the Dynamic user equilibrium . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Input and output attributes of the dynamic user equilibrium (DUE). . . . . . . . . .
References to the appropriate modeling for a DUE assignment . . . . . . . . . . . .

Evaluation of the Dynamic stochastic assignment . . . . . . . . . . . . . . . . . . . . . . 422


Input and output attributes of the dynamic stochastic assignment . . . . . . . . . . 422
Procedure of the dynamic stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . 423

NCHRP 255 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425


Assignment analysis PrT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426

User model PuT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429


6.1
6.2
6.3
6.4

Overview of PuT assignment procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429


Example network for the PuT assignment procedures . . . . . . . . . . . . . . . . . . . . 431
PuT paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
PuT skims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
6.4.1
6.4.2
6.4.3
6.4.4

6.5
6.6
6.7
6.8

Evaluation of the headway-based assignment . . . . . . . . . . . . . . . . . . . . . . . . .


Headway calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generalized costs as impedance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Choice models for boarding decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The complete choice model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The search in general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example for the transport system-based assignment . . . . . . . . . . . . . . . . . . . .
Coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

453
454
456
459
465
470
471
474

Timetable-based assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477


6.10.1

PTV AG

Evaluation of the transport system-based assignment . . . . . . . . . . . . . . . . . . . 451


Example for the transport system-based assignment . . . . . . . . . . . . . . . . . . . . 451
Steps of the transport system-based assignment . . . . . . . . . . . . . . . . . . . . . . . 452

Headway-based assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453


6.9.1
6.9.2
6.9.3
6.9.4
6.9.5
6.9.6
6.9.7
6.9.8

6.10

437
446
447
447

PuT impedance functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448


Distribution of the travel demand to PuT connectors . . . . . . . . . . . . . . . . . . . . . 448
Allocation of skims with reference to lines/links . . . . . . . . . . . . . . . . . . . . . . . . . 449
Transport system-based assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
6.8.1
6.8.2
6.8.3

6.9

PuT skim categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Perceived journey time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Temporal utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Evaluation of the timetable-based assignment . . . . . . . . . . . . . . . . . . . . . . . . . 477

VII

Contents

6.10.2
6.10.3
6.10.4
6.10.5
6.10.6
6.10.7
6.10.8

6.11
6.12

Assignment analysis PuT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .506


PuT Passenger surveys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .509
6.12.1
6.12.2
6.12.3
6.12.4
6.12.5

Basic data of a passenger trip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510


Passenger onboard survey: Basic approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Read survey data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Plausibilization of survey data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Assignment of survey data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519

Operator model PuT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521


7.1

Application areas and scope of operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . .521


7.1.1
7.1.2

7.2
7.3
7.4

7.5

Introduction to the line blocking procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532


Application example for line blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
Data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Line blocking description without vehicle interchange . . . . . . . . . . . . . . . . . . . . 563
Line blocking description with vehicle interchange. . . . . . . . . . . . . . . . . . . . . . . 573
Line block display and editing in the timetable editor . . . . . . . . . . . . . . . . . . . . . 578
Vehicle requirement and line blocking indicators . . . . . . . . . . . . . . . . . . . . . . . . 579
Description of the PuT interlining matrix procedure . . . . . . . . . . . . . . . . . . . . . . 581

PuT fare model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .582


7.5.1
7.5.2
7.5.3
7.5.4

7.6

Calculation of indicators on different aggregation levels . . . . . . . . . . . . . . . . . . 522


Introductory examples for PuT indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523

Network objects in the Operator model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .530


Typical work flow in the PuT operator model . . . . . . . . . . . . . . . . . . . . . . . . . . .531
Line blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .532
7.4.1
7.4.2
7.4.3
7.4.4
7.4.5
7.4.6
7.4.7
7.4.8

Ticket types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585


Fare systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
Fare calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
Application of fares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604

PuT operating indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .605


7.6.1
7.6.2
7.6.3
7.6.4
7.6.5
7.6.6
7.6.7
7.6.8

VIII

Connection search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478


Connection preselection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Impedance and Perceived journey time PJT of a connection . . . . . . . . . . . . . . 481
Connection choice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Handling of public transport systems of the PuT-Aux type. . . . . . . . . . . . . . . . . 491
Opening of the timetable-based assignment: Export/Import of connections . . . 492
Capacity restriction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499

Example for PuT operating indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605


Indicators for line route and timetable evaluation . . . . . . . . . . . . . . . . . . . . . . . . 609
Measurement of the transport supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
Measurement of the network performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
Calculation of operating costs and fare gains (revenues) . . . . . . . . . . . . . . . . . 622
Calculation of the operating costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
Calculation of the fare revenues (revenue calculation) . . . . . . . . . . . . . . . . . . . 632
Basic calculation principles for indicators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641

PTV AG

Contents

Environmental impact model and HBEFA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651


8.1

Noise volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651


8.1.1
8.1.2
8.1.3

8.2

Air pollution emissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654


8.2.1
8.2.2

8.3

EWS Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663


EWS link attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666
EWS Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668
EWS Cost-benefit analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669

GIS functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671


10.1
10.2

Connection to the Personal Geodatabase and GIS objects . . . . . . . . . . . . . . . . 671


Shape files as a GIS interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672
10.2.1
10.2.2

10.3
10.4
10.5

10.6

Importing shape files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672


Exporting shape files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675

Intersect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677
Coordinate systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Processing the network display with graphic objects . . . . . . . . . . . . . . . . . . . . . 688
10.5.1
10.5.2
10.5.3
10.5.4

11

Fundamental principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657


Basics of the HBEFA calculation in Visum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657

Economic assessment according to EWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663


9.1
9.2
9.3
9.4

10

Pollution-Emis procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654


Pollutant-Emis link attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655

Emission calculation according to HBEFA 3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 657


8.3.1
8.3.2

Noise-Emis-Rls90 procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651


The Noise-Emis-Nordic procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
Link attributes for noise calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652

Texts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Legend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backgrounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Polygons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

688
688
689
694

GPS tracking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695

Interactive analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697


11.1

Flow bundles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697


11.1.1
11.1.2
11.1.3
11.1.4
11.1.5

11.2

PTV AG

699
701
705
706
711

Isochrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
11.2.1
11.2.2
11.2.3

11.3

Flow bundle definition through selection of network objects . . . . . . . . . . . . . . .


Flow bundle definition through selection of traffic types . . . . . . . . . . . . . . . . . .
PuT supply filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Combining flow bundle criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Flow bundles with alternative routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

PrT isochrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715


PuT isochrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717
Combination of PrT and PuT isochrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720

Shortest path search. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722

IX

Contents

12

Tabular and graphical display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725


12.1

Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .726
12.1.1
12.1.2
12.1.3
12.1.4

12.2
12.3
12.4
12.5
12.6
12.7
12.8
12.9
12.10
12.11
12.12
12.13

List display and entry options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726


Specific network object lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
Matrix list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
Evaluation lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731

Bars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .733
Categorized display with attribute values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .736
Labeling with tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .740
Labeling with charts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .741
Turn volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .743
Desire lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .744
Stop catchment areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .746
PuT transfer relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .748
PuT connections and transfer flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .749
Lane allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .750
2D display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .752
Schematic line diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .754
12.13.1
12.13.2
12.13.3
12.13.4

Defining and editing a schematic line diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 754


Display of supply in the schematic line diagram. . . . . . . . . . . . . . . . . . . . . . . . . 754
Display of demand and transfer flows in the schematic line diagram. . . . . . . . . 756
Saving layout information and transferring layouts to variants . . . . . . . . . . . . . . 756

12.14 Signal time-space diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .757


12.15 Column charts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .759
12.16 Evaluations in the timetable editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .760

Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
List of illustrations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
List of tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787

PTV AG

Fundamentals of the program


PTV Visum (Visum) is a software system that allows you to model all private and public
transport types in one single integrated model. It is complemented by the microscopic traffic
simulation system PTV Vissim (Vissim). Using Visum, most basic data provided by transport
information and planning systems can be managed consistently and maintained with the
network editor. Unlike simple GIS systems, Visum allows complex relationships within single or
several transport systems to be retained, enabling you to create a suitable transport model.
A transport model normally consists of a demand model, a network model based on Visum and
various impact models (illustration 1):

PTV AG

The demand model contains travel demand data. Information on the demand within a
planning area is required for the analysis of transportation networks. Demand matrices can
only partially be created based on survey data. This is why mathematical models are used
to reproduce real demand ratios. They allow you to calculate the traffic flows between
zones of the planning area based on structure and behavior data, the spatial utilization
structure and the transport system. Visum includes the Standard 4-step model, the EVA
model, and the Tour-based model. Thus you can create your own travel demand matrices
in the program (see "Demand model" on page 119).
The network model stores the transport supply-side. The network model consists of traffic
zones, nodes, public transport stops, links representing roads and railway tracks, and the
public transport lines with their timetables. Transport supply data can be visualized with
Visum and edited interactively with different methods.
The impact models use input data provided by the network model and the demand model.
Visum offers several impact models for analysis and evaluation of transport supply. The
user model simulates the travel behavior of public transport passengers and car drivers
(see "User model PuT" on page 429 and "User model PrT" on page 211). It calculates
traffic volumes and service skims (such as journey time or number of transfers). An
operator model determines operational indicators of a public transport service, like service
kilometers, service hours, number of vehicles or operating costs (see "Operator model
PuT" on page 521). Revenues by ticket type derived from the demand data allow line
related revenue estimates for a line costing calculation. An environmental impact model
offers several methods to assess the impacts of motorized private traffic on the
environment (see "Environmental impact model and HBEFA" on page 651).
Visum displays the calculation results in graphical and tabular form and allows you to
perform various graphical analyses of the results. You can e.g. display and analyze routes
and connections per OD pair, flow bundles, isochrones and turning volumes at nodes.
Indicators such as journey time, number of transfers, service frequency, and many more
are computed as skim matrices.
You can compare different versions using the version comparison or network merge
functionalities. You can further exchange the changes made to your model via model
transfer files.

Chapter 1: Fundamentals of the program

Transport model
Demand model

Network model

contains demand data:


Origin, destination,
number of trips by
demand segment.
Temporal
distribution of travel
demand.

contains supply data:


Transport systems,
traffic zones,
nodes and stop points,
links,
PuT lines with line routes and time
profiles.

Impact model
contains methods to determine impacts:
User model:
assignment, calculation of service indicators,
Operator model:
number of vehicles, line costing, revenues,
Environmental model:
pollution and noise emissions.

Results
Listings and statistics
Indicator matrices
Graphical analysis
Plots

(calculated attributes of network objects and routes)


(journey time, service frequency, ...)
(flow bundles, isochrones, ...)

Illustration 1: Visum network model and impact model

Like all models, a transportation represents an abstraction of the real world. The aim of the
modeling process is system analysis, forecasting and model-based preparation for decisions
taken in the real world.
In the following, especially the network data model and the procedures available in Visum are
described and explained in a simple way.

1.1

Network model the transport supply


A network model representing the comprehensive transport system must describe the spatial
and temporal structure of the transport supply. For this reason, the network model consists of
several network objects which contain relevant data about the link network, the lines and
timetables and traffic zones. The most important network object types in Visum are described
here.

PTV AG

Chapter 1.2: Transport demand model

Zones (also called traffic cells) describe areas with a particular land use and their location
in the network (for example residential areas, commercial areas, shopping centers,
schools). They are origin and destination of trips within the transport network, which means
zones and the transport network are connected through connectors.
Nodes are objects which define the position of intersections in the link network and of
switches in the railway network. They are start and end points of links.
Links connect nodes and thus describe the rail and road infrastructure. A link has a
particular direction, so that the opposite link represents a separate network object.
Turns indicate which turning movements are permitted at a node and store the turning time
penalty.
Connectors connect zones to the link network. They represent the access and egress
distances to be covered between a zones center of gravity and the nodes/stops of the
network.
Stops are subdivided into stop areas and stop points served by lines where passengers
may board or alight.
Lines which are listed with a name in a timetable usually go into both directions. A line can
consist of several line variants, so-called line routes which differ for example, in their route
courses. Line routes describe the spatial course of line services, for each line route one or
several time profiles can be defined.
Territories are network objects, which can be used for example, to model districts or
counties. Based on a polygon which defines the territorial border, PrT and PuT indicators
for regular or single PuT line services can precisely be accounted for each territory.

Every network object is described by its attributes. Attributes can be subdivided as follows:

Input attributes such as link length or link number.


Calculated attributes (output attributes) such as boarding passengers at a stop or the
number of assigned vehicles. They are only filled with values in the course of calculation
procedures.

For all network object types, users can define additional so-called user-defined attributes. They
can contain additional information or temporary values which are like "normal" attributes
presented in lists and graphically, and are available as filter criteria. Because these are not
required to understand the basics, no further detail is required at this point.
The integrated network model distinguishes between transport systems of the private transport
and the public transport type. PrT transport systems depend on permissible speed and link
capacity. PuT transport systems are bound to a timetable.

1.2

Transport demand model


Travel demand develops when a sequence of activities (home - work - shopping - home)
cannot be carried out at the same location and thus requires a trip.
The travel demand is stored in a matrix, where all zones contained in a traffic model are in
columns and rows.

PTV AG

A PrT demand matrix element has the unit car trips, a PuT demand matrix element has the
unit passenger trips (do not mistake with the vehicle journey of a PuT line). It contains the
number of travel demand from a traffic zone i to a traffic zone j.

Chapter 1: Fundamentals of the program

A travel demand matrix refers to a time interval (analysis time interval) and thus only
contains trips which depart within the time interval.
Trips of a demand matrix can refer to the total transport system, to partial transport systems
(for example pedestrian, bicycle, PuT, car), to person groups (for example employed,
students, retired persons) or to purposes (for example commuting, shopping, leisure).
A demand matrix is assigned to exactly one demand segment. A demand segment
describes a group of road users with homogeneous travel behavior.

Travel demand can be divided into surveyed and calculated demand as well as into today's
and future demand.
Surveyed travel demand describes the number of trips and the trip distribution within a fixed
time interval for an existing transport supply system. It represents a snapshot of the current
traffic situation and cannot be reproduced again practically. An exact survey of today's
current travel demand in an area of interest is not possible in practice because all travelers
would have to be interviewed at the same time. For this reason, only a representative, random
sample of travelers is interviewed to determine travel demand for the purposes of
transportation planning. From this survey a matrix of today's travel demand is then deducted.
It represents the travel demand for the existing supply system.
Calculated travel demand contains assumptions about the number of trips and trip
distribution. To calculate travel demand, demand models are used which, for example,
differentiate between the three steps of Trip generation, Trip distribution and Mode choice. The
calculated travel demand can be designated differently depending on the used input data.

Calculated travel demand is called today's travel demand if the input of the demand
calculation is today's land use structure, today's population and economic structure, and
today's transport supply system.
Forecasted travel demand is based on data on future land use, future population and
economic structure and the future transport supply system.

An overview of the procedures for determining travel demand can be found in Leutzbach et al.
(1988).
Within Visum all 4 stages of the classical traffic model (4-step model) can be calculated,
besides traffic assignment (choice and volume of the route to get from origin zone to
destination zone) the other three steps Trip generation, trip distribution and Mode choice
(choice of means of transport), too.
In the first step of the classical model, Trip generation, the production and attraction (origin and
destination traffic) of each zone is determined on the basis of socio-demographic data (for
example, number of inhabitants and jobs). These production and attraction values define the
totals of the total demand matrix, which is determined by means of relevant skim data (for
example, journey times, fares etc.) in the second step, Trip distribution. In the third step the
total demand matrix is distributed onto the different traffic modes (for example, PrT, PuT) on
the basis of mode-specific skims. In a fourth step the resulting mode-dependent demand
matrices can be assigned to the supply (Visum network) by means of the PrT and PuT
assignment procedures in order to obtain link volumes and new skims. This skim data can
again be used as inputs for trip distribution or mode choice of a new demand calculation. The
Go to the procedure function allows you to iterate the calculations until a convergence
criterion concerning link volumes or matrix values is satisfied.
Visum contains three alternative calculation models for the demand modeling.

PTV AG

Chapter 1.2: Transport demand model

The Standard 4-step model is based on North American practice for aggregated demand
models (see "Standard 4-step model" on page 126).
The EVA model is another aggregated demand model for passenger demand. It differs
from the Standard-4-Step Model by a simultaneous trip distribution and mode choice as
well as by its particular method of balancing the differences between origin and destination
traffic (see "EVA model for passenger demand" on page 132).
When calculating demand matrices, the Tour-based model (traffic in cities generation
model) takes into consideration activity chains which homogenous-behavior user groups
(for example employees with or without a car, pupils, students) perform during the course
of the day (see "Activity chain based model (tour-based model)" on page 161).

The matrix editor integrated in Visum supports matrix processing and provides a gravity model.
The calculation models are based on specific Visum demand objects describing the
characteristics of trip purposes and road users. Person groups combine road users featuring
comparable mobility behavior to groups. The break-down of the population into person groups
may be based on their job status (employed, students, retired persons) and (optionally) their
car ownership (with/without car). Activities are activities or locations of a person in the course
of the day which are not traffic related (work, school, home). Activity pairs describe transitions
between two activities and may imply trips from one place to the other (home - work, home school). They are then called trip purposes.
A demand stratum combines one or several person groups with an activity. Almost all
calculations of the first three stages of the model are carried through separately for each
demand stratum and their results are stored separately for a better illustration and verification.
The resulting demand matrices always have the unit [persons].
By aggregating the demand strata to demand segments parts of the demand jointly to be
assigned are combined prior to the fourth stage, which is the assignment. Hereby, the PrT
demand matrices are converted into the [Vehicles] unit by dividing the demand stratum
matrices by the occupancy rate of the respective transport system.

Temporal distribution of travel demand


The trips from one traffic zone to another traffic zone in reality take place at different times. The
temporal distribution of travel demand within the analysis period is described by a start time
and a time series when modeling in Visum. The time series is taken into consideration at the
PuT assignments and the dynamic PrT assignment. The demand distribution is ignored in the
case of static PrT assignments. Temporal distribution of the trips within each time interval of an
observed time period can therefore not be set for this procedure.
The start time specifies the time and if the weekly or annual calendar is used - the day on
which the period referred to by the demand in the matrix starts. The end of the period is
calculated from the length of the assigned time series.
Time series can be defined in two different ways:

proportional time series of one demand matrix


as a distribution curve consisting of several demand matrices

A time series by percentage specifies the proportion of trips with the desired departure time
within the respective time interval. Demand distribution curves can cover more than 24 hours
if a weekly or annual calendar is used. An equal distribution of travel demand during the
observed time period is assumed as default. Instead of this default, a user-defined demand
distribution curve can be specified for the entire matrix. This user-defined demand distribution

PTV AG

Chapter 1: Fundamentals of the program

curve can be overwritten again for selected pairs of origin-destination zone types with specific
demand distribution curves. In this way, it is possible to specify deviating distribution curves for
zones, for example, with known structural features (for example purely residential or
commercial areas) that reflect the different traffic loads in one direction (illustration 2) at certain
times of the day for journeys between home and work.
%
40
35
30
25
20
15
10
5
0
7:00

7:30

8:00

8:30

9:00

Illustration 2: Example of the temporal distribution of travel demand by four intervals of 30 minutes

A time series of demand matrices allocates a separate matrix to each time interval which
contains the demand with the desired departure time in the respective time interval. It should
be used if for example matrices on an hourly basis already exist based on a trip generation
model. Contrasting time series, here the time dependent course of the demand can be freely
selected for each matrix item. However, the data entry expenditure and the memory
requirements are higher accordingly, because several complete matrices are supplied.

1.3

Impact models methods to calculate the impact of traffic


A transport supply system has diverse impacts which may vary because of measures (for
example the construction of a new tram line or a bypass).

Impacts on the user of the transport system


Impacts on the operators who have to produce a transport service
Impacts on the general public who benefits from the transport infrastructure but also has to
pay for it
Impacts on the PuT contractor which may have to account for a political deficit
Impacts on the environment which is harmed by pollution

Transport supply-side users


Users of infrastructure for private transport are mostly car drivers and their passengers, but
also non-motorized travelers such as cyclists and pedestrians. Users of public transport are
public transport passengers.

PTV AG

Chapter 1.4: Analysis of results

Transport supply-side operators


The road network is usually operated by the state, federal states or communities and
increasingly by private investors. These operators of the road network have to decide on
investments for the construction and maintenance of road infrastructure. PuT operators are the
transport companies and transportation agencies. In the broader sense, the PuT contractors
also belong to the operators. To offer public transport service, PuT operators develop line
networks and timetables from which the user can then choose connections. To organize
drivers and vehicles, PuT operators develop vehicle employment plans and rosters.

Models to calculate the impact of traffic


Visum includes different models which are used to determine the impacts of given transport
supply.

1.4

Different assignment procedures make it possible to assign current or anticipated travel


demand to existing or planned transport supply. The most important information of these
assignment procedures are network object volumes (link volumes for example).
The connection quality of each transport systems or for the selected demand segments is
described via skims, which can be output in skim matrices (impedance matrices).
The environmental model makes it possible to determine noise and/or pollution emissions
of motorized private transport for traffic volumes in the existing or planned transport
network.
An operator model determines the operational and financial requirements of PuT supply,
projection of data to analysis period or analysis horizon, as applicable, is possible. The
number of required vehicles is computed by a line-blocking calculation procedure, which
are necessary to be able to offer the PuT supply.

Analysis of results
Transportation demand and the results of the impact models can be evaluated and output
under different aspects. The following functionalities are available (see "Tabular and graphical
display" on page 725 and "Interactive analyses" on page 697).

PTV AG

Flow bundles, which filter demand segment-specific paths traversing network objects
selected by the user (nodes, links, zones, stop points, stop areas and stops)
Flow bundles for the analysis of network volumes according to traffic types (origin,
destination, through, external, internal and bypassing internal trips)
Turn volumes, which display PrT turning flows at intersections
Isochrones for classifying the reachability of network objects and for comparing PuT
journey times and PrT travel times
Graphical shortest path search for the PrT, which visualizes the shortest path between
zones or nodes in the network for a PrT transport system
Graphical shortest path search for the PuT, which visualizes the shortest path between
zones, nodes or stop areas. The shortest paths can be based on transport systems or
determined on the basis of the timetable provided in Visum
Skim matrices describe different properties for each OD pair from origin zone to a
destination zone in the traffic model. Each skim (such as the in-vehicle-time) is derived from
the properties of all paths found from origin zone to a destination zone
7

Chapter 1: Fundamentals of the program

1.5

Lists for all network object types, which allow a tabular display of all attribute values of a
network object
Display of bars, charts and tables on the map (for example to visualize the link volumes)
Statistics for the assignment analysis and the analysis of the assignment quality. This is
how the coefficient of determination R2 can be determined approximately between the
volumes calculated in the assignment and the observed values, and the assignment model
can continue to be calibrated.
Column charts for the display of time series (for example link volumes in the course of the
day)
Graphic and tabular display of vehicle journeys in the Timetable editor. This is how
volumes from the assignment can be displayed as bars for each journey.
Comparing and transferring networks (Network merge, Version comparison, Model
transfer files)

Comparing and transferring networks


Visum offers various possibilities to compare and transfer networks and version files:

Version comparison (see "Comparing version files" on page 9)


Network merge (see "Network merge" on page 14)
Model transfer files (see "Model transfer files" on page 17)

Version comparison and network merge


Besides the network merge, two version comparison variants are provided:

Version comparison with transfer of selected direct attributes


Version comparison with comparison network loaded in the background

In contrast to the first variant, which includes the transfer of selected attributes into the opened
version, the second variant builds relations to the loaded network in the background. This
means that all attributes of the loaded network are visible in the opened version. Additionally to
the existing relations to other objects (for a node, for instance, to the in-links, out-links, turns
etc.) another relation to the loaded network will appear in the attribute selection windows.
The unique feature of the network merge is the unification of different data.
The following table gives an overview of the essential differences between network merge and
version comparison. In most cases you will be working with the new version comparison in
future.

Version comparison

Network merge (previously difference network)

Normal working is possible. For the relations,


simply additional evaluation attributes/values are
created, which can be deleted or updated, if
required.

Special mode serving mere evaluation purposes,


hardly editable, not savable

Simultaneous comparison of various variants


possible

Comparison with exactly one variant

PTV AG

Chapter 1.5: Comparing and transferring networks

Version comparison

Network merge (previously difference network)

New evaluation attributes/values of relations are


listed with original attributes, i.e. graphic
parameters, filters etc. can still be used

Evaluation attributes replace original attributes, i.e.


graphic parameters, filters etc. have to be adjusted

Evaluation attributes (beside value of original


network): Value of comparison network, difference,
relative difference, minimum, maximum

Evaluation attributes: Value of original network,


value of comparison network, difference, DiffNet
(see "Network merge" on page 14)

According to the type of version comparison, either


attributes are selected or relations are built to all
objects

All attributes and network object types are


compared.

Updatable by pushing a button

Not updatable

Model transfer files


A model transfer file allows recording the modifications required to transfer a model, i.e. a
combination of network data and OD demand data, to another model. You generate the model
transfer file from two version files, whereby data can be limited to selected network object types
or attributes. You can exchange modifications between the different version files at any time,
and equally maintain several scenarios.

1.5.1

Comparing version files


The version comparison provides easy and quick access to attribute values from other network
variants. Therefore, compared to the Network merge function, this function is more suitable
for networks basically including the same network objects. The table below lists the differences
of the two version comparison variants.

PTV AG

Version comparison with transfer of attributes

Version comparison with comparison network


in the background

Attributes of the comparison network are


transferred during the version comparison and will
be saved with the version file.

Via a relation to the comparison network, all


attributes are automatically available as long as this
network is loaded in the background. When the
program session is closed, the attributes of the
comparison network will not be stored with the
version. Nevertheless they will be displayed when
the session is reopened.

The direct attributes selected are adopted.

All direct and indirect attributes can be analyzed.

Filters are not regarded.

Filters in the opened network are also evaluated in


the comparison network. There they have an effect
on indirect attributes with the 'Active' reference.

Updating means, that current attribute values of the


comparison network version are used to overwrite
the values of preselected attributes in the opened
network version. A prerequisite is that the storage
location of the comparison network was not
changed.

Updating means, that the path can optionally be


changed and then the comparison network is be
reloaded in the background. Reopening a version
with such a comparison complies with an update as
described in the column to the left.

Chapter 1: Fundamentals of the program

Version comparison with transfer of attributes

Version comparison with comparison network


in the background

When you delete the version comparison, the


comparison network attributes are removed from
the opened network.

To prevent automatic comparison network loading


in the background, the reference to the comparison
network has to be removed.

The values of the selected attributes of the opened


network and the comparison network are displayed
underneath the attribute of the particular object in
the opened network.

The attributes of the comparison network become


visible via an additional relation to the loaded
network. All attributes and relations of the
comparison network are subordinated to this
relation.

Use cases for version comparison


The examples 1 - 3 can be modeled with either version comparison variant. In these cases, the
decision which of the variants to use will depend on the form the attributes and relations shall
exist in the opened network and whether the results of a snapshot will be required in the future.
Example 1: You have increased the capacity of a link corridor or extended the timetable of PuT
lines. By comparing the assignment attributes of each version comparison you can analyze
how and where these measures are having impact.
Example 2: For one network you have calculated assignments in two different version files, e.g.
for different OD demand data. Then you can compare the typical assignment attributes like
Volume and Passengers transferring as well as the modified OD demand data directly by
means of a version comparison.
Example 3: In two version files you have performed line blockings under different constraints.
You can compare the different results, for example the number of vehicles per vehicle
combination, by means of the version comparison.
Note: Using the model transfer file you can transfer the network data and the OD demand
data of the compared models (see "Model transfer files" on page 17).
The examples 4 and 5 are typical applications which require comparison network loading in the
background. In other words, these cases can only be modeled with this version comparison
variant.
Example 4: You have two networks with identical infrastructure, only the PuT supply is
different. By link bars, varying volumes shall be visualized which depend on the various criteria
provided for selection (line name, valid day). For that purpose, indirect link attributes are
required, which refer to a filtered supply, e.g. Sum:LineRouteItems\Sum:UsingTimeProfile
Items\SumActive:VehicleJourneyItems\Volume(AP). The filter in the opened network is
evaluated in either network, i.e. in the particular context of each network. In this way, you can
easily display the link volume differences.
Example 5: You would like to visualize all links with different PuT line S5 volumes in the two
networks. In the opened network, two filter conditions are set: Via the line filter, line S5 is
selected. This filter criterion can be evaluated in both networks. This evaluation is independent
of the particular other network, it causes changes to indirect attributes with reference 'Active' in
either network. In the link filter it has to be specified that the difference of the link volumes
differs from zero (network B\this network - comparison network\Sum:LineRouteItems\Sum:
UsingTimeProfileItems\SumActive:VehicleJourneyItems\Volume (AP) 0), i.e. in the opened
network, the relation to the comparison network provides access to the calculated difference.
10

PTV AG

Chapter 1.5: Comparing and transferring networks

This includes indirect active attributes. The link filter criterion can only be evaluated in the
opened network.

Version comparison with transfer of attributes


Read one or several version files to an already opened version file for comparison. As a result
of this version comparison Visum automatically creates attributes containing the selected
attribute values of the other version files. You can recognize the newly added attributes
because the attribute name (table 1) is suffixed by the code labeling the comparison.
In case of numerical attributes Visum automatically adds various comparison attributes: For
each compared numerical attribute additional attributes are created for the absolute difference,
the relative deviation as well as the minimum and maximum.
By way of example the following table lists the seven additional attributes which are created for
the numerical attribute Volume PrT (AP) when comparing version A with version B.
New attribute

Short name English

Long name English

Value of network B

VolVehPrT,B(AP)

Volume PrT [Veh] B (AP)

Absolute difference A-B

VolVehPrT,-B(AP)

Volume PrT [Veh] - B (AP)

Absolute difference B-A

VolVehPrT,B-(AP)

Volume PrT [Veh] B - (AP)

Relative deviation regarding B (A-B)/B

VolVehPrT,-B%(AP)

Volume PrT [Veh] - B % (AP)

Relative deviation regarding A (B-A)/A

VolVehPrT,B-%(AP)

Volume PrT [Veh] B - % (AP)

Minimum of both attribute values

VolVehPrT,B,Min(AP)

Volume PrT [Veh] B Min (AP)

Maximum of both attribute values

VolVehPrT,B,Max(AP)

Volume PrT [Veh] B Max (AP)

Table 1: Additional attributes for a compared numerical attribute after version comparison

The values of the additionally read attributes cannot be modified manually. However, all
calculated values, i.e. all values except the value of network B, are recalculated automatically
as soon as the corresponding values of network A are modified.
With the version file containing the version comparison you can continue to use all Visum
functions, including calculations. The comparisons read can be saved together with the
version.
The additionally read attributes can be displayed and evaluated, as required (see "Analysis of
results" on page 7).

PTV AG

11

Chapter 1: Fundamentals of the program

Illustration 3: Network of the original version

Illustration 4: Network of the version used for version comparison

12

PTV AG

Chapter 1.5: Comparing and transferring networks

Illustration 5: Network with version comparison: The volumes of both versions compared as well their
difference are displayed. "Verscomp" is the name of the version comparison.

Above all, you can convert the attribute values of the additionally read version easily into userdefined attributes so that they are still available after the version comparison has been
terminated.
The reference to the additionally read data is not updated automatically, but can be updated, if
required. Thus, for example, you can read the same version file at different times, thus tracing
the modifications.
The reference to the additionally read data can be dropped again at any time.

Special cases
If the compared versions do not contain the same network objects or attributes, the following
will happen (opened version: A, additionally read version: B)

If an object exists in B only, it does not appear in the version comparison.


If an object exists in A only, the attribute values of B are empty.
Note: You can use the attribute Exists in network <Code of version comparison> to
check whether a network object is available in one of the compared versions.

PTV AG

If an attribute exists in B only, it cannot be selected for the version comparison.


If an attribute exists in A only, it is not compared.
If the sub-attributes of an attribute are different in A and B, only those sub-attributes valid
in A are considered. Sub-attributes which do not exist in B have an empty attribute value.

13

Chapter 1: Fundamentals of the program

Version comparison with comparison network in the background


For an opened version file, one or several selected version file(s) are loaded in the background
as comparison networks. Thus, all attributes (indirect attributes included) of the comparison
network become visible in the attribute selection windows via the relation to the loaded
network. This relation is identified by the code of the version comparison. In the opened
network, new possibilities are provided especially through the combination of filters and
indirect attributes with aggregate functions which regard the active objects. You can define
filters in the opened network and apply them to both networks in a given context. In this way,
indirect attributes can systematically be evaluated in an easy way by just modifying the filter
criteria.
Similar to the version comparison with attribute transfer, for numerical values additional
comparison attributes are generated such as relative deviation, difference, maximum and
minimum. Furthermore, they can also be converted into user-defined attributes subsequently
to the selection.

Special cases
Objects are generally identified via their key. Using the opened network version (network A),
you can create a relation to the object in the comparison network (network B). If the compared
versions do not contain the same network objects or attributes, the following rules apply:

1.5.2

If an object exists in B only, access to this object is only provided via indirect attributes (e.g.
a node existing in B only belongs to all nodes in B - the latter is a relation within network B,
to which a relation from network A refers).
If an object exists in A only, the attribute values of the relation to B are empty.
If an attribute has different sub-attribute variants in A and B, then indirect attributes provide
access to the variants which exist only in B. If there is no sub-attribute variant in B, then the
attribute value calculated for the relation is empty.

Network merge
The network merge function provides for the comparison of two transport networks and the
output of their differences. For network merge any networks can be combined with each other.
After that, however, only evaluation functions are available, hardly any editing functions.

Use cases for network merge


For project management you want to determine the differences between two Visum models.
Occasionally there are two different version files available for one project (for example for
different scenarios) and you want to be able to relate to the differences in the two models.
Two variants of one model usually differ in that some attributes of a few network objects have
different values. If, for example, you model different expansion statuses of the same network
in two version files, there will be deviations in the Number of lanes and Capacity PrT
attributes of some links, for instance. Furthermore, network objects can only be in one of the
two models and missing completely in the other. If for example, one of the two models contains
a planned case with an additional by-pass, the respective links will be missing in the other
model.
The following illustrations show both cases. Compared to Network 1, Network 2 contains an
additional link. The two networks further have different TSysSet and v0PrT values.

14

PTV AG

Chapter 1.5: Comparing and transferring networks

Illustration 6: Network 1 used for merge network

Illustration 7: Network 2 used for merge network

The merge network


The two models to be compared, network 1 and network 2 have to be available as version files.
If you open both version files in the network merge mode, Visum shows a so-called merge
network. The merge network is created by first identifying all objects which occur in both
models. Two objects are the same if they have identical key attributes. Compulsory references
to other network objects (for example, for links the keys 'From Node' and 'To Node') must
correspond. Exceeding this intersection of the network objects, objects which only occur in one
of the two models are also transferred to the merge network. This is the main difference
compared to version comparison. The disadvantage to be put up with is the limited editability.
Additionally, a calculated DIFFNET attribute is created for each network object. It reflects the
status of the network object.

PTV AG

In network 1: Only network 1 contains the object, network 2 does not.


In network 2: Only network 2 contains the object, network 1 does not.
DIFF: Network 1 and 2 both contain the object, with at least 1 attribute having different
values in both networks.
EQ: Network 1 and 2 both contain the object, all attributes are identical in both networks.

15

Chapter 1: Fundamentals of the program

In no network: The object exists only in the merge network and has no attribute values.
Example: A turn between a link of network 1 and a link of network 2. Such objects are
created in rare cases, so that the merge network is a permissible Visum network. They
have no real equivalent and no attribute values.

In the merge network, a read-only attribute is created for each network 1 and/or network 2
attribute (Visum attributes and user-defined attributes). This attribute has the following
properties:

The attribute has identical properties as in network 1 or network 2.


The attribute has a sub-attribute with values Network1, Network2 and Difference.
Network1 and network2 indicate the original attribute values stored with each original
network version file if the object is part of the original network version; otherwise, 0 or blank
is output.

The Difference sub-attribute value serves to output the difference and has the following
values.
For numerical attributes, the difference is calculated from Net1 and Net2 data
For strings, "==" is output in case of identical strings, whereas "<>" indicates deviating
strings. Blanks are output for objects which are not part of both original network
versions.

Note: In case of user-defined attributes with identical IDs but different min/max value ranges,
the value range of Net1 will be used. For objects with coordinates, the coordination values are
taken from network 1for the display in the network.
Note: Network merge ignores the following objects and settings:
Junction geometry/control objects
Demand description (neither matrices nor time series)
All path information
Analysis periods and horizons
Filters
Blocks
Graphic parameters

16

PTV AG

Chapter 1.5: Comparing and transferring networks

The illustration 8 displays the merge network of network 1 (illustration 6) and network 2
(illustration 7).

Illustration 8: Merge network of network 1 and network 2

In the network view of the merge network, you can see that the link at the bottom left of network
2 has a lower speed of about 20 km/h and varies in TSysSet. The link at the bottom right is,
however, identical in both networks.

Characteristic: Analysis time intervals


In case of identical analysis time intervals of network 1 and network 2 (ID and interval limits),
these intervals are equally stored with the merge network. In case of deviating interval
properties, no intervals will be created in the merge network. The conformity of the analysis
periods and horizons is not checked. Attribute values which refer to different analysis periods
or horizons in network 1 and network 2 will still be stored with the merge network.

1.5.3

Model transfer files


Using model transfer files you can save the difference between two models, i.e. network data
and OD demand data. A model transfer file created that way can be applied again to a suitable
version file in order to add the modifications. With this function it becomes easier to manage
the different scenarios.
Scenario management is based on model transfer files (see "Managing scenarios" on
page 18).
When creating the model transfer file, you can specify which data you want to save. However,
just like when saving a network, make sure that your choice contains the information you need.
Example: You would like to adjust the timetable of one network to that of another one. The PrT
attributes of the networks are different, which is to remain unchanged. In this case, when
creating the model transfer file, you only select the network objects with regard to the
timetables.

PTV AG

17

Chapter 1: Fundamentals of the program

Use cases for model transfer files


In your network you make certain modifications at one point, for example, you insert new links
or delete others. You save these modifications as model transfer file. Then based on the
original network you plan further variants and save them each equally as model transfer file. If
now modifications have to be made in the original network, you can easily redo the various
variants using the model transfer files and even combine them with each other, if required, by
reading several model transfer files consecutively one after the other.
In another case it may happen that one editor creates and edits zones and saves these
modifications to a model transfer file. In the meantime, a second user has edited links, reads
the model transfer file and adds the new zones to his network.

1.6

Managing scenarios
In most Visum applications you create a model of supply (the network) and demand for an area
of investigation. Then you develop several variants of the initial situation and various
scenarios. The variants are then compared and evaluated based on calculation results.
Thereby numerous files (including and excluding calculation results) are created for the
individual variants. You can use the Compare networks function to organize the file contents,
making sure that information is only saved to one storage location (see "Comparing and
transferring networks" on page 8). This allows you to reduce data maintenance when changing
your model. In Visum, scenario management takes care of maintaining all your files.
It provides the following benefits:

1.6.1

Visum saves all project files in a standard folder structure.


Visum provides a clear project overview, showing all variants of your model. When you
enter a meaningful name for a variant and its parts, your entry is not limited by any file
system specifications.
To edit a variant, use it in calculations or for analyzing results, simply open it by entering its
name in the project view (you will not have to search for it in the Windows file system).
When you perform calculations or comparisons across all variants, scenario management
spares you many manual steps and automatically merges the calculation results of several
variants. You can easily adopt the results in form of a comparison table into your project
report.

Keywords: project, modification, scenario


Scenario management has three main concepts: project, modification and scenario.

18

PTV AG

Chapter 1.6: Managing scenarios

A project contains all data required to use Visum. It has a unique name and a protocol in which
users can save notes on the project status. Each project is based on a base model which is
also called initial situation, analysis case or null case. It is saved as a version file, the so-called
base version. Just as other supporting files (procedure and graphic parameters, etc.), the base
version is saved to a uniform folder structure for which you can specify the path. All other
project information, specifically definitions of modifications and scenarios, are saved to the
Visum project database, a database file that is saved to the same folder structure.
A modification is a grouping of changes that belong together content-wise and are made to the
supply or demand. A modification could refer to the building of a by-pass road and include
several new links, changes to existing links and to nodes. Another modification might describe
the introduction of a speed limit on certain roads. It would consist of changing a single attribute
(v0) for several network links. Modifications may also refer to PuT supply, for example
describing line route or headway changes as well as new stops. On the demand side, typical
modifications include changes to data on the socio-demographic structure, i.e. changes to the
zone attributes. Modifications may also change matrix content, e.g. externally specified
matrices for through trips. The number of modifications is not limited per project. Modifications
may also be based upon other modifications, e.g. one describes the construction of a by-pass
road and another its extension by a second lane per direction. The second modification only
changes the attributes Capacity PrT and Number of lanes for those links that were added
through the first modification of the base model. When creating a modification, you specify the
other modification it is based on.
A scenario corresponds to a variant you want to investigate. It is often also called planned
case. Each scenario is based on the base version of the project and includes one or several
modifications. The distinction between modification and scenario has the advantage that you
can easily investigate all combinations of several measures. Let us assume your project is
about the construction of a by-pass road. At the same time it is suggested to introduce a speed
limit in the city center for traffic calming. Define two modifications for your project: M1 for the
by-pass road and M2 for the speed limit. Using these two modifications, you can easily define
four scenarios without any additional modeling effort:

PTV AG

19

Chapter 1: Fundamentals of the program

Scenario code

Meaning

Base version

M1

S0
B

M2

Null case

by-pass road only

speed limit only

BS

by-pass road + speed


limit

Table 2: Definition of scenarios based on modifications

Should your customer additionally ask for an investigation of the demand variant for 2020, you
can change your project with a minimum effort. First define a modification M3 for the second
demand variant. Then duplicate all previously created scenarios and in the copy additionally
activate M3. Now you are ready to calculate the model for all eight scenarios.
Scenario code

Meaning

Base version

M1

M2

M3

S0

Null case

by-pass road only

speed limit only

BS

by-pass road + speed limit

S0_2020

Null case 2020

B_2020

by-pass road 2020 only

S_2020

speed limit 2020 only

BS_2020

by-pass road + speed limit


2020

Table 3: Extension of scenarios for a demand variant

When combining scenarios based on modifications, make sure that the modifications do not
contain any contradictory information on the value of the same attributes. Visum can account
for this and check whether it is possible to combine two modifications. In few cases, you might
want modifications to overlap. Example: M1 describes the extension of a link sequence to two
lanes. M2 includes a third lane for some of the same links. For some links, M1 and M2 contain
contradictory information on the attribute Number of lanes. If you first apply M1 and then M2,
you will still achieve the desired result: for some links the attribute Number of lanes will be
overwritten twice. This way you need not define a copy of M1 without the links mentioned in the
original M1. In these cases, it is important that you can specify in which sequence the
modifications are applied. To avoid conflicts when combining scenarios, you can also specify
which scenarios must not and which ones may be combined when defining the modification.

1.6.2

Managing projects efficiently


A project is ideally carried out in the following steps:

20

Creating or selecting a base version


Defining modifications
Defining scenarios based on modifications

PTV AG

Chapter 1.6: Managing scenarios

Specifying the procedure sequence


Calculating scenarios
Comparing calculation results

All steps are carried out in the Project view. The Project view is a modeless window and
remains open while you are working on the project. It provides an overview of all modifications,
scenarios and other parts of the project.

You can find a detailed description on how to use the Project view in the User Manual (see
User Manual, Chpt. 1.13, page 115). In the following, you will find useful information on each
step.

1.6.2.1

Creating or selecting a base version

When working on a new project, you first specify the version file of the base model. In most
cases, the version file already exists. Especially, if you have already started working on the
project without using scenario management. Select the existing version file, when creating the
project. Visum stores a copy of this version file with a different name to the project directory
structure. This copy is now used in scenario management. The original version file is not
touched. Alternatively, you can use the model currently loaded as the base version. If you
select this option just after project start, the model will still be empty and you can create your
base model from scratch. All options are equally suitable to create a base model, no matter
whether you create the model within the context of scenario management or of a project. The
project becomes important once you define modifications and scenarios.

PTV AG

21

Chapter 1: Fundamentals of the program

1.6.2.2

Defining modifications

When adding a new modification to your project, you assign a unique name and a project
description, if required. You further specify any existing modifications your new modification
depends on and the ones it cannot be combined with. Visum then loads the base version and
all its modifications. A floating window informs you that all changes you now make to the model
will be included in the new modification.

Now you can use all editing functions to change the model. Data processing, however, is
disabled in the Project view. After making all your changes, click the Finish button in the
floating window. Visum calculates the differences between the current model and the base
model. These differences are saved as content of the new modification.
Of course you can add modifications during any stage of your project. You can also change
modifications later on. You can further have the content of modifications displayed any time.
If you are working on an extensive project, you might want to assign the creation of
modifications to several users. To do so, proceed as follows:

Provide each user with a copy of the base version.


Each user works with his/her copy of the base version, without using scenario
management. As soon as a user has completed a modification, he/she saves the changes
made to the base version as a model transfer file.
Make sure you have access to all the model transfer files created.
Open your project in Visum. Then carry out the following steps for each model transfer file:
Add the modification to your program.
When Visum asks you to change the modification based on the base version, select
Model transfer file as the only option.
Then finish editing the modification.
Now define your scenarios based on the modifications.

This procedure allows you to use files centrally under scenario management, although they
were created decentrally by several users.
Note: If several users are working on creating model transfer files, they might use the same
code for a new network object, although the content of their objects differs. Visum will
recognize these code conflicts when you use the model transfer files in scenario
management. So, if the same code has been assigned twice, one of the objects is
automatically assigned a new, unique code.

22

PTV AG

Chapter 1.6: Managing scenarios

1.6.2.3

Defining scenarios based on modifications

After you have defined modifications for your project, you can combine them to create
scenarios. Scenarios are also assigned a unique name and a description. For each scenario,
you can choose several modifications that are applied to the base version. If you do not select
a modification, the scenario simply corresponds to the base model. If you select several
modifications, Visum applies them according to the sequence in your list of modifications. Then
check to make sure the modifications you selected can be combined. You can also remove or
add modifications to a scenario later on.
Under Project view, you can open any scenario in the entry view or the results view. Choose
the entry view to check the scenario or to perform an interactive analysis, e.g. isochrones
calculation or shortest path search. Avoid editing the model in this view, as your changes
will then be lost the next time you open the scenario. Instead, always make your changes
to the base version or the modifications. If you save a scenario as a version file, your version
file will have no connection to scenario management. However, you can use it to pass on the
entry data of a certain scenario to other users. The results view is described further below.

1.6.2.4

Specifying the procedure sequence

In most cases you will want to apply the same model calculation to several or all scenarios in
order to compare the results. By default, Visum uses the procedure parameters of the base
version to calculate a scenario. To specify the calculation sequence, in the Project view, click
the Edit base version button. Then, under Procedure sequence, choose the sequence in
which you want the operations performed.
Some operations require reading or writing access to files, e.g. to externally saved skim
matrices or filter files. Under Project view, you specify whether Visum has access to one file for
the entire project or to file copies of the respective scenarios. You can specify this for all files
of a certain type or globally for the entire project.
However, sometimes you might want to use a different than the default calculation sequence
for a scenario, e.g. when changing the procedure parameters. If you do not wish to change the
network or demand in a scenario, but the Value of Time, change the fare or toll coefficient in
the impedance definition. These parameters are not taken into account for difference
calculation when you create modifications. Instead change the procedure parameters of the
base version and add the edited procedure parameters file to the project. Then close the base
version without saving the changes. Assign the scenario the procedure parameters saved to
the project. This setting has a higher priority than the procedure parameters of the base
version.

1.6.2.5

Calculating scenarios

After specifying the calculation sequence for the project, assign it to all or part of the scenarios
in the Project view. If you select several scenarios, Visum will automatically load the scenarios
in the sequence selected and will perform the respective calculations. This function is very
helpful if you have to carry out numerous calculations, e.g. overnight, and no interaction is
required. Moreover, you can distribute scenario calculations across multiple computers to
exploit the computing power available (see "Distributing scenario calculations across multiple
computers" on page 24). After all calculations have been performed, Visum saves the model

PTV AG

23

Chapter 1: Fundamentals of the program

state with all results to a version file in the project directory. Saving the results of each scenario
to a separate version file might seem like a "disruption" of scenario management, but this is the
only way to save the many results (e.g. assignment results) in a compact form.
In the Project view, the scenarios for which calculations have been performed are marked
"calculated". If after scenario calculation you change the base version, its modifications, the
calculation sequence or the number of modifications, Visum will reset the status to "not
calculated". The results version file then still exists, but the results might no longer be up-todate and you should have the calculation performed again.

1.6.2.6

Distributing scenario calculations across multiple computers

You can distribute scenario calculations across multiple computers to calculate multiple
scenarios simultaneously and obtain the results earlier for analysis purposes. You do not
require any additional system or other software, provided that the add-on module is licensed.
Then you can use all software belonging to the license group installation of Visum.
Workstations used during the day for project work, e.g., can be used at night for extensive,
automated scenario calculations (see User Manual, Chpt. 1.13.7.2, page 130).

Requirements for distributed scenario calculation


Besides licensing for the add-on module, the computers used for distributed calculation
(compute node) must fulfill certain requirements:

24

The computers must have compatible Visum versions installed (with the same binary
version, e.g. 13.00-xx).
All computers must be licensed for the add-on modules required for calculation and for an
adequate network size.
If you are using Python scripts or add-ins, the respective Python version and add-ins must
be installed on the computers.
Depending on the use case, ensure that additional resources, e.g. HBEFA data files or
user-defined VD functions, are available on the computers. Project-specific data is
automatically copied to the respective computers by Visum.
Do not specify absolute paths for additional files, e.g. matrices or scripts, within the
procedure used for scenario calculation. On the compute node, the files might not be
available under the path specified. Only specify project folders available within scenario
management.
Ensure the same program options are selected on each computer. This is not done
automatically.
The computers must be connected via the network. If required, in the firewall of the
computers, open the ports used for communication and assign the corresponding user
rights. The ports can be freely selected. The compute nodes must be located in the same
subnetwork as Visum to be found automatically by the program. If this is not the case, you
can still use them for distributed calculation. However, you need to enter the computer
addresses manually.
The PTV Visum Scenario Calculation Server of the respective installation must run on
the compute node. Only if this software is run, can the calculation orders be carried out. The
Scenario calculation server is automatically installed with Visum. It is not necessary to start
Visum on the compute node.

PTV AG

Chapter 1.6: Managing scenarios

The Scenario calculation server is not a Windows service. The software is only run when a
user logs on to the computer.

Setting up the compute node


The Scenario calculation server receives the calculation requests and controls execution of the
calculations. When you do not want to use the compute node for distributed calculation, e.g.
during the day when it is used for project work, deactivate it.
You can start the software via the Start menu of the respective Visum installation or via the
symbol in the Windows taskbar. Click the symbol to open the dialog for configuration of
the Scenario calculation server.

Illustration 9: Configuration of the Scenario calculation server

Besides the number of Visum instances and cores you want to use, you can specify a Base
directoryto which the scenario data is saved during the calculation process. In the Service
address section, specify the name and port under which the compute node shall be available.
You can use the same computer to simultaneously run multiple instances of the Scenario
calculation server for different Visum installations, e.g. different service pack versions. To do
so, for each installation, you must start the Scenario calculation server and configure a different
port. Each server started uses the respective Visum version located in its installation folder.
The Base address of the service box contains the URL based on these settings. If the
compute node is not automatically found by the controlling Visum version, the URL can be
used for manual configuration. You can select the option Start Visum Scenario Calculation
Server when logging in to start the server automatically, as soon as a user logs on to the
system.

PTV AG

25

Chapter 1: Fundamentals of the program

Execution of distributed scenario calculation


Distributed calculation is carried out by any computer in the Visum Project view. On the
Compute node page, you can manage existing compute nodes as well as input and output
files relevant for calculation. Here the nodes available are automatically identified. You can
also manually add compute nodes by entering their URL. By default, the Input data transferred
to the compute node includes all files of the shared Project folder and the respective Scenario
folder. If required, additional files may be added manually or excluded from data transfer, e.g.
to save data transfer time or storage space on the compute node. By default, the result files
consist of the respective Scenario folder files that are transferred back to the controlling
computer. Here you may also add files to or exclude files from data transfer.
To start distributed calculation, as in local calculation, on the Scenarios page, select the
scenarios of your choice and click Calculate. At the beginning of the calculation process, you
can assign the scenarios to individual compute nodes. You can also choose whether you want
to have the result files of the compute node automatically transferred back to the respective
folders.
After you have started the calculation, Visum transfers the files required to the compute nodes
(if the current files are not already available there). In the Project view, the scenario overview
shows the calculation step currently carried out. During the calculation procedure, you can use
the controlling Visum to perform other tasks or simply close it. The calculation process is
continued autonomously on the compute node. After the calculation has been completed, the
scenario indicators calculated are listed. They are now available for scenario comparison. If
specified during calculation start, all other result data is also listed, so that you can analyze the
scenarios using the tools you are familiar with. If the result data is not automatically listed, you
can list it for selected scenarios. The scenarios are then available for local calculations and
analyses.

1.6.2.7

Analyzing and comparing calculation results

You need not open the results version file in the Windows file system. In the Project view,
simply open the respective scenario in the results view. Visum then loads and displays the
resulting version file and all functions are available for analysis of the results for this scenario.
If you want to compare two or several scenarios with each other, highlight them in the Project
view. Then specify one of them as the master scenario. In the master scenario, open the
version comparison. Visum shows a comparison of the master scenario with each of the other
scenarios. Version comparison works the same way when used outside scenario management
(see "Comparing version files" on page 9). In the course of the project, you are likely to use
version comparison many times. You can combine the parameters of version comparison
(optionally also graphic parameters and filter settings) to a so-called comparison pattern and
save it to the project. Then you can open version comparison in the Project view, without
having to change the settings again each time.
You can also compare all scenarios at a glance by using selected, network code numbers. You
specify the code number in the Basic settings tab of the Project view. They can then be
selected as columns in the Scenarios tab. You can use them to create a table with the
scenarios as rows and the columns containing the code numbers.

26

PTV AG

Chapter 1.6: Managing scenarios

You can use the Copy & Paste command to copy this table to a project report.

PTV AG

27

Chapter 1: Fundamentals of the program

28

PTV AG

Network model
The supply data of the transport network are described in a network model consisting of
various network objects.

Subjects

2.1

Network objects
Spatial and temporal correlations in Visum
Attributes
Subnetwork generator
The surface data model in Visum

Network objects
The network model differentiates basic network objects such as nodes and links, which
illustrate a network structure (see "Basic network objects of a transport network" on page 29).
Additionally, there are network objects which are only used for modeling PuT networks (see
"PuT network objects of a transport network" on page 31) and general network objects, which
do not have to have any relevance to traffic and especially no influence on procedure
calculations (see "General network objects" on page 33).
Network object

Description

Transport system
(TSys)

The transport supply consists of several transport systems. Transport systems


are used for example, to allocate attributes for network objects dependent on
transport systems. This is how links can be opened for a transport system bike,
for the transport systems car and HGV blocked, however.

Mode

In PrT a mode comprises exactly one transport system. In PuT, however, a


mode can comprise several transport systems. This is how you can define a
mode PuT for example, which comprises the PuT transport systems tram, bus
and train.

Demand segment
(DSeg)

A demand segment makes the connection between transport supply and traffic
demand. A demand segment is assigned exactly one mode and each demand
segment exactly one demand matrix. A mode can comprise several demand
segments. This is how you can create a demand segment for the mode PuT, for
transporting students and one for the remaining PuT.

Node

Nodes are point objects, which specify the location of intersections, merging
links or points in road and rail network. They are start and end points of links.
Nodes connect zones with the network (connected nodes).

Table 4: Basic network objects of a transport network

PTV AG

29

Chapter 2: Network model

Network object

Turn

Turn standard

Link
Link type

Zone

Connector

Main node

Main turn

Main zone

Territory

Description
Turns specify which movements are permitted at a node, that is, whether
turning at a node from one link to another link is permitted.
For PrT transport systems, turning time penalties and capacities can be
specified which describe the influence of the intersection on the performance of
the network.
Turning prohibitions are taken into consideration as follows:
For public transport systems in the construction of a line route
For private transport systems in a route search
Turn standards are templates used to create new turns with default values for
the attributes Time penalty and Capacity PrT. Which turn standard is used for
the allocation of turn attributes, depends on the node type, the turn type and the
flow hierarchy.
Links connect nodes and thus describe the structure of the road and rail
network. A link is a directed edge, i.e. both directions of a link are independent
network objects and thus, can have different attributes.
Link types are used as a template when inserting new links. When inserting a
link, a link type has to be specified. The link then takes over the attributes
permitted transport systems (TSysSet), Capacity PrT, velocities (v0-PrT,
vMin-PrT, vMax-PrT und vDef-PuT), Number of lanes and the link rank as
default values.
Zones (traffic cells) describe the positions of utilities in the network (for
example, residential areas, commercial areas, shopping centers, schools).
They are origins and destinations of movements within the transport network,
which means of traffic. Zones and the transport network are connected through
connectors.
Connectors connect zones to the link network. They represent the distance to
be covered between a zones center of gravity and the connector nodes. For
public transport demand, the zone has to be connected via a stop area with
stop(s) allocated to a node.
Several nodes can be aggregated to one main node. Each node is only allowed
to be part of a main node. Using main nodes is useful, if the Visum network is
strongly disaggregated and lanes are available as individual links, for example,
and intersections therefore consist of several nodes (this situation can occur
when working with navigation networks in Visum).
Main turns are created when using main nodes. Each movement via the main
node is represented by a main turn. Main turns possess the same attributes as
turns. In the assignment, the main turn replaces the node turn, which has the
effect that only one turn penalty flows into the assignment for each main turn.
Main zones group multiple zones and allow aggregated evaluations. A main
zone can represent a county for example, which has multiple communities as
traffic cells.
Territories are network objects, which can be used for example, to illustrate
districts or counties. Based on a polygon which defines the territorial border, PrT
and PuT indicators can be precisely accounted for each zone (for example the
driven service kilometers within a zone).

Table 4: Basic network objects of a transport network

30

PTV AG

Chapter 2.1: Network objects

Network object

Description

OD pair

OD pairs exist between all zones of the network. The values in skim matrices
and demand matrices (see "Matrices" on page 120) refer to one OD pair each.
Compared to the other network objects, you cannot edit OD pairs interactively
in the network editor, but you can filter OD pairs and display them graphically.
For each OD pair you can select the skim matrix values, the demand matrix
values and the direct distance as attributes.

Path

For assignment calculation, paths are found between the origin and destination
zone, and their volume is calculated. Paths are therefore the central result of
the assignment procedure. In PrT, the user can manually edit paths. This is how
the assignment results could be manually imported to Visum or the Visum
assignment results could be adjusted manually. Both the path volumes and the
course of the path can be edited.

Valid day

Valid day is a freely definable set of days of the calendar used. If a weekly
calendar is used, a valid day may comprise the days from Monday to Sunday
(e.g. "Monday to Friday"). If an annual calendar is used, any individual days can
be selected within the validity period. If no calendar is used, there is only the
valid day "daily". It is then not possible to create new valid days.
In PuT: a valid day can be assigned to each vehicle journey section.
In PrT: in the Dynamic stochastic assignment and DUE, traffic supply can be
time-varying. Time-varying attributes are used (see "Time-varying attributes" on
page 105). When using a calendar, valid days can be specified for these timevarying attributes, on which they should have an effect.

Table 4: Basic network objects of a transport network

Network object

Description

Stop

A stop combines stop areas and therefore also stop points. To ensure that a
stop can be localized and displayed in graphical form, it has a coordinate, but it
is not assigned directly to a network node or link.

Stop area

Stop point

A stop area divides a stop into areas. It can, for example, represent a train
station platform, intersections with multiple stop points or a station concourse.
A stop area has the following properties:
It is assigned exactly one stop.
It can comprise multiple stop points.
It can be assigned a network node. This allows a PuT connection of a zone
to the road network.
The stop areas are connected with each other with a transfer walk matrix
(walk times between the stop areas). It contains the transfer walk time of
each PuTWalk for example.
A stop point is the location, where PuT lines stop for passenger boarding. A
stop point can either lie on a node or on a link (link stop point).
A stop point at a node can be served by all lines which pass the node.
A stop point on a link can only be served by lines which pass this link. A
detailed direction modeling based on masts is optionally possible with link
stop points. Alternatively, undirected stop points can also be inserted on
links.

Table 5: PuT network objects of a transport network

PTV AG

31

Chapter 2: Network model

Network object

Line

Description
Lines combine all line routes and timetables of a line. A line has at least one line
route and this at least one time profile. For line variant modeling, several line
routes can be specified for the line, and several time profiles can be specified
for each line route.

Line route

Line routes describe the spatial course of the line route for one direction as a
sequence of route points. Route points are selected points in the line routes,
namely all stops and possibly traversed nodes. The first and last route point of
a line route must be stop points that are open for the transport system of the
line.

Time profile

Time profiles describe the length of travel times between stop points of a line
route and if boarding or alighting is allowed at the stop points of the line route.
Since it is possible to create several time profiles per line route, you can model,
for example, that the travel times of a tram between stop points are longer
during evening rush hours than during the rest of the day. Time profiles are
allocated at vehicle journey level so that each vehicle journey can be allocated
a different time profile.

Vehicle journey

Vehicle journeys (also called journeys only) are the basic objects to describe
the timetable. Each vehicle journey has exactly one time profile. In most cases
all vehicle journeys of a line route use the same time profile, if this does not vary
depending on the time of day.

Vehicle journey section Vehicle journey sections (also called journey sections) are used to sub-divide a
vehicle journey. You can define different valid days and different vehicle
combinations for the individual vehicle journey sections of a vehicle journey.
This is how you can achieve, that a train travels on days with high saturation
with a vehicle combination, which has more coaches attached. Furthermore,
you can specify different start and end points for each vehicle journey section,
and therefore achieve for example, that the additional coaches are only
attached to one part of the line route course.
Main line

System route

Main lines are used to aggregate several lines and evaluations (such as for PuT
operating indicators) on this aggregation level. Aggregation can also be carried
out via lines with different transport systems.
A system route describes the in-vehicle time and the spatial course between
two stop points. Compared to the line route, it is independent of the affiliation to
a line or even a concrete vehicle journey. System routes with their path and invehicle-time information are used as a template for the efficient digitalization of
line routes and for setting in-vehicle-times in the time profile. System routes are
optional network objects, therefore not mandatory when creating a PuT model.

PuT operators

You can assign an operator to each vehicle journey section. When working with
the operator model, you can evaluate PuT operating indicators per operator
(see "Operator model PuT" on page 521). Furthermore, you can assign each
operator cost values for depreciations and running costs, and then evaluate
operator costs referring to different network objects.

Vehicle combination

You can optionally assign each vehicle journey section a vehicle combination.
To a vehicle combination you can allocate time and distance dependent cost
rates for vehicle journeys and empty trips, and cost rates for the layover in the
depot and the stand time. These cost rates are applied within the operator
model (see "Operator model PuT" on page 521).

Table 5: PuT network objects of a transport network

32

PTV AG

Chapter 2.1: Network objects

Network object

Description

Vehicle unit

A vehicle combination consists of one or more vehicle units. This is how you
can compose a vehicle combination Intercity out of several vehicle units
Coach, for example. For each you can specify the number of seats and total
seats. Furthermore, you can assign time and distance dependent cost rates for
vehicle journeys and empty trips, and cost rates for the layover in the depot and
stand time. You can also define a fixed cost rate per vehicle. This allows much
differentiated modeling of your vehicle pool.

Block version

In Visum multiple line blocking results can be kept simultaneously. These are
saved in so-called block versions. This is how alternative plans with different
parameter settings can be compared with each other. In the model, for example
one block version can be kept where interlining is allowed, and another block
version where it is not allowed.

Block item type

Each block is composed of individual sections, which are called block items.
Each block item is of a special type (block item type). By default, Visum
provides the block item types vehicle journey, empty trip, layover time, and
stand. You can also create user-defined block item types and include these
manually in your blocks (for example for maintenance or wash).

Ticket type

If revenues are modeled with a fare model, the ticket type creates the basis for
the fare calculation of a connection. Basic fares and transport system
dependent supplements can be defined.

Fare zone

For revenue calculation with fare model and zone-based fare, fare zones are
used to calculate the fare of a connection. For the zone-based fare this
complies with the number of traversed fare zones. To determine the number of
traversed fare zones, stops are assigned to the fare zones.

PuT coordination group This network object is only relevant for headway-based assignment. If there are
two lines for example, which complement each other on a common section of
the route course to a headway interval half the length, we speak of
coordination. The coordination group combines two or more time profiles over
a common section of the line courses. If two or more time profiles were
coordinated via a route section, they behave like a time profile with a
corresponding increased frequency on this section. The random variable,
which illustrates the waiting time within headway-based assignment, thus is
reduced to the coordinated section.
Table 5: PuT network objects of a transport network

Network object

Point of Interest (POI)


and POI category

Count location

Description
Points of Interest are user-defined network objects with a spatial reference, e.g.
parking facilities, pre-emption points for AVLS (automatic vehicle location
systems) or SCJ controllers in public transport. POIs are used to display special
land uses such as restaurants or hotels, for data management as well as for
reachability analyses.
A count location is an independent network object allocated to a link by
direction. Count locations serve for data management and display of counted
link data.

Table 6: General network objects

PTV AG

33

Chapter 2: Network model

Network object

Description

Detector

Detectors are optional network objects of the count locations add-on. They are
used for lane-based management of counted data and for signal control
modeling.

Toll system

Toll systems are optional network objects which can be used to integrate toll
zones into the network model. For the TRIBUT procedure, they are the basis for
the calculation of road tolls.
GIS objects (GIS = geographic information system) extend the network model
by special layers which are directly incorporated from GIS ArcGIS and can be
linked with the Visum network data via blending features. The objects are only
available during the connection with a Personal Geodatabase (PGD).

GIS object

Screenlines are a useful construction to calibrate an assignment model by


means of counted link data. The course of screenlines often follows natural
realities, for example rivers or railway tracks.

Screenline

Table 6: General network objects

Network processing modifies the properties of the transport network which produces different
indicator values and assignment results.

2.1.1

In the case of modifications to the network structure, a current assignment result is


initialized. Inserting, deleting or renumbering a network object as well as merging nodes,
splitting zones or links and aggregating zones represent modifications to the network
structure. PuT assignment results are kept if new zones and connectors are inserted.
As long as only attribute data of network objects are modified, for example the length of a
link, the current assignment result will not be initialized, although another assignment might
produce a different result.

Transport systems, modes and demand segments


The transport supply consists of several transport systems. Modes and demand segments are
used to link the transport supply with the transportation demand.
Priv.TSys1
(e.g. HGV)

Priv.TSys2
(e.g. Car)

HGV

Car

Publ.TSys1
(e.g. Bus)

Park&Ride
(Car, Bus, Tram)

Publ.TSys2
(e.g. Tram)

Publ.Transport
(Bus+Tram)

Transport systems

Modes

HGV

Carprivate

Carbusiness

P&R

Publ.Transp
Students

Publ.Transp.
Adults

Demand
segments

Matrix

Matrix

Matrix

Matrix

Matrix

Matrix

Demand
matrices

Illustration 10: Connection between transport systems, modes, demand segments and demand matrices

34

PTV AG

Chapter 2.1: Network objects

2.1.1.1

Transport systems

The transport supply consists of several transport systems. Links, turns and connections can
be attributed subject to the transport system ("transport system-based"). It can be specifically
determined, if a transport system is allowed to traverse one of these network objects or not. For
example, links can only be opened for the transport system Car, but not for the transport
system HGV. Furthermore, the impedance functions (see "Impedance and VD functions" on
page 216) are defined for the assignment transport system dependent.
A transport system has the following properties:

Transport system type (available are PrT, PuT, PuTWalk or PuTAux)


Means of transport (= vehicle type), for example car, tram, taxi, wheelchair

Note: The number of modeled transport systems, modes or demand segments is not limited.
The four types of transport systems are different in the following ways.

PTV AG

PrT
Travel times of a private transport system depend on the following attributes:
Maximum speed of the means of transport for example 100 km/h for HGV
Permitted speed of the traversed link for example 80 km/h
Capacity of the traversed link
PuT
Run times of vehicles of a public transport system and the dwell times at stops are
determined by the timetable.
PuTWalk
This mode serves to model entrance and exit paths for public transport and walking transfer
links between stop points of a stop or several stops. In order to calculate a public transport
assignment, at least one transport system of type PuTWalk must exist. Several transport
systems of type PuTWalk can be defined.
PuTAux
This type describes subordinated PuT transport systems without a specified timetable. It is
suitable for the following use cases.
Modeling lower-ranking public transport (supply systems):
In large networks, for example in train networks, one often does not want to enter the
reachability of long-distance stations by means of a connector, but in instead one wants
to roughly display the available public transport supply. For a simple representation
such as this, it is meaningful to define one or several additional public transport
systems. In this case, the successive public transport supply is only described as a link
network with run times. Line routes and timetables are not used.
Modeling different types of public transport connectors:
A zone is connected to the PuT supply via one or several PuT systems. In many cases,
passengers not only select nearby start stops for their PuT journey that can be reached
on foot, but they also select distant stops that can be reached by bicycle or car
(Park&Ride, Kiss&Ride, Bike&Ride). In order to be better able to model these
alternatives, for connectors it is possible to disable individual transport systems of type
PuTWalk or to define different connector times. Two modes can then be defined for the
PuT assignment: one mode that is only used if the stop is reached on foot and one
mode that can be used if the stop is reached by car or bicycle.
35

Chapter 2: Network model

Note: Transport systems of type PuTAux are only taken into consideration for the
transport system-based and timetable-based assignment. In headway-based
assignment, however, they are not considered.
The table 7 provides an overview of properties of the transport system types:
TSys type

Description

Example

PrT

Transport system for private transport


Capacity-dependent travel times resulting from link speed and
turn times

Car,
HGV

PuT

PuT with timetable


Bus,
Tram,
Run times from timetable
Transport system is not valid for transfer walks or on a connector Train

PuTAux

Public transport system without timetable or


Bus,
PrT access system to PuT
Taxi,
P&R access
Run times result from links
Transport system is not valid for transfer paths within a stop - just
between stops

PuTWalk

Transport system for


access/egress paths from/to stops or
transfer paths within a stop or between stops
Travel times from links or from a transfer walk time matrix of the
stop

Footpath,
Escalator,
Lift

Table 7: PrT transport systems properties

2.1.1.2

Modes

A mode can include either one private transport system or several public transport systems.
Examples for modes are for example:

HGV mode
Transport system HGV
PuT mode
all PuT transport systems, for example bus, tram, subway
Park & Ride mode
PuT transport systems and transport system PuTAux car

You can define multiple PuT modes. This way it is possible to model that for example longdistance passengers (Mode PuT-Long) may use all public transport systems (e.g. Intercity,
Regional train, Bus) whereas, for example, commuters (Mode PuT-Local) may use only
particular transport systems (Regional train, Bus).

2.1.1.3

Demand segments

A demand segment belongs to exactly one mode. It is the link between transport supply and
transport demand. As several demand segments can be defined for each mode, different types
of demand can be combined in the transport model.

36

PTV AG

Chapter 2.1: Network objects

Demand segments can be used for differentiation among

Population groups
Employed PrT (car drivers), Employed PuT, Students PuT, etc.
Ticket types
Single trip ticket, monthly pass, etc.
Trip purposes
to work, shopping, home
Vehicle types
Car - diesel, Car - petrol, etc.

To each demand segment a demand matrix is assigned. Assignment results therefore always
exist on the level of a demand segment (for example the volume for the demand segment PuT
pupil transport).
In principle, it is assumed that demand matrices are available in the following units.

PrT
in car units (CarUnits)
PuT
in passenger units

For the calculation of person trips (PrT) from car units, the occupancy rate can be specified for
each demand segment (see User Manual, Chpt. 2.11.3.2, page 243).

Assignment of demand segments


In all private transport assignment procedures (see "User model PrT" on page 211), demand
segments of different PrT modes can be assigned simultaneously.

Tribut procedure, Stochastic or Dynamic stochastic assignment


Per iteration step, a route search is carried out for each transport system, because each
transport system has a transport system-specific impedance function.
Incremental and Equilibrium assignment, Equilibrium_Lohse assignment
The search for each demand segment is carried out individually, using the same TSysspecific impedance function. This means, that volumes can be issued by DSeg. Adding the
demand matrices prior to the assignment saves calculating time.
DUE
Due to the parameterization by demand segment, the route search is always carried out by
TSys.

For public transport, only the demand segments of one public transport mode can be selected
for assignment calculation (see "User model PuT" on page 429). For modeling more than one
PuT mode (for example PuT-Long, PuT-Local), a separate assignment is required for each
mode, as route search needs to consider different transport systems. For each demand
segment, particular split parameters can be defined (see assignment parameters). This serves
to model for example, deviating tolerance levels towards transfers or of specific fares due to
the tariff (students, employees, pensioners).

2.1.2

Nodes and turns


Nodes specify the location of intersections, merging links or points in road and rail network.
Turns specify which movements are permitted at a node.

PTV AG

37

Chapter 2: Network model

2.1.2.1

Node

Nodes determine the locations of street junctions and points in the railway network. They are
starting and terminating elements of links, where there are turning relations from one link to
another in PrT or PuT transport systems (see "Turn" on page 38). Optionally, a major flow can
be defined for every node specifying the direction of the flow with the right of way. The major
flow which has the right of way can be determined automatically by Visum from the ranks of the
intersecting links (see "Links" on page 40). Any number of nodes can be incorporated in a main
node (see "Main node" on page 48). Impedances can be modeled for nodes, which then have
an effect on the route search and thus on the assignment results (see "Impedances at node"
on page 226). This is how influential factors on time can be integrated in the assignments,
which a vehicle needs to cross an intersection.

2.1.2.2

Turn

Turns indicate whether turning is permitted at a node and what time penalty has to be
considered for PrT transport systems.

For private transport systems, time penalty and capacity can be specified which describe
the impact of the intersection on the network performance. Turns are considered for PrT
transport systems during assignment.
For public transport systems turning prohibitions are considered during the construction of
a line route and during transport system-based PuT assignment.
Turns representing a change of direction are important for PuT line blocking.

When inserting a link, Visum creates all theoretically possible turns at both nodes of the link
and uses the standard values from the user-defined turn standards.
For example, at a four-way intersection, there is a total of 16 turns (4 right turns, 4 straight
ahead, 4 left turns and 4 U-turns).
Each turn is described by the following elements:

A list of permitted/not permitted transport systems


PrT capacity
PrT time penalty
Actual change of direction

For each turn, the transport systems have to be specified which may use this turn. A turn
differentiates permitted and blocked transport systems.
Permitted PuT
transport systems

The turn can be used when constructing the line route.

Permitted PrT transport The turn can be used for the assignment taking the PrT capacity and the PrT
systems
time penalty into account.
Blocked transport
systems

Prohibited turns

Per default, the following rule applies when you insert a new turn:

38

All turns are open to all transport systems that are allowed on both the "from link" and the
"to link". This also applies to u-turns.

PTV AG

Chapter 2.1: Network objects

An exception are the PuTWalk transport systems: These are not automatically incorporated
into the transport system set of turns.

2.1.2.3

Turn types

Visum distinguishes 10 turn types (0 to 9), of which types 0 to 4 are predefined.


0: Not specified
1: Right turn
2: Straight ahead
3: Left turn
4: U-turn
5: Free for user-defined cases
The turn type can be calculated automatically from the geometry of the turn.

2.1.2.4

Turn standards

Turn standards are templates which assign a newly created turn with values for their attributes
Turn time penalty (t0-PrT) and Capacity. Which turn standard is used to assign attributes of
each turn, conforms to the three following criteria.

the type of node, via which the turn runs


the type of turn (right, straight ahead, left)
the flow hierarchy which depends on the rank of a link entering a node

For each node, Visum evaluates the rank of the links involved and thus determines a major
flow (see "Link types" on page 41). This automatically determined major flow can be edited
manually. The flow hierarchy describes whether a turn follows this major flow, from this one
into a minor flow, from one minor flow into the major flow or leads from minor flow to minor flow.
These four steps of the flow hierarchy are designated with the symbols from table 8.
Symbol

Right of way

++

from major flow into major flow

+-

from major flow into minor flow

-+

from minor flow into major flow

--

from minor flow into minor flow

Table 8: Flow hierarchy symbols

In combination with node types, turn types and flow hierarchy, you can assign the turns very
differentiated turn times as standard. These turn times can then be considered within the
assignment (see "Impedances at node" on page 226). The illustration 11 shows an example of
turn standards.

PTV AG

39

Chapter 2: Network model

* Attention: Time always in seconds


* Table: Turn standards
$TURNSTANDARD:ID;NODETYPE;TURNTYPE;FLOWHIERARCHY;T0PRT;CAPPRT
1;10;1;--;10s;32000
2;10;1;-+;10s;32000 // Right turn from minor flow into major flow
3;10;1;+-;10s;32000 // Right turn from major flow into minor flow
4;10;1;++;0s;32000
// Road with right of way which bends to the right
5;10;2;--;15s;32000 // Crossing from minor flow into minor flow
6;10;2;-+;10s;32000
7;10;2;+-;10s;32000
8;10;2;++;0s;32000
// Crossing straight from major into major flow
9;10;3;--;20s;32000
10;10;3;-+;20s;32000 // Left turn from minor flow into major flow
11;10;3;+-;15s;32000 // Left turn from major flow into minor flow
12;10;3;++;0s;32000
Illustration 11: Example of a TURNSTANDARD table in the network file, which is used to specify standard
values for turn penalties and turn capacity

2.1.2.5

PrT capacity and PrT turn time

Turns show basically the same correlation between capacity and travel time as links. The only
difference results from the fact that a turn does not have a length and that the travel time t0
therefore comes from the turn time penalty.
The turn time tCur in the loaded network then results from the selected VD function and the
relationship between the current traffic volume q and the capacity qmax:

Input: Free flow turn time t0 (turn time penalty) [s]

Input: Volume q of the turn [car units/analysis time interval]


Input: Capacity qmax of the turn [car units/analysis time interval]

Input: VD function, for example BPR function from U.S. Bureau of Public Roads
Result: current turn time in the loaded network (1), for example

b
q
t cur = t 0 1 + a ------------------
q max c

(1)

To model turn times which do not depend on capacity, a constant VD function must be chosen.
How the impedance at a turn depends on these parameters in particular, depends on the set
method for impedances at nodes (see "Impedances at node" on page 226).

2.1.3

Links
Links describe roads and railways of the transport network. They connect nodes, which means
intersections in PrT or stop points in PuT. A link is represented as a directed element and is
described by the From Node number and To Node number. Both directions of a link are two
independent objects in the network model, who are assigned the same link number and whose
From Node number and To Node number has been swapped. This means, that you can
attribute both directions of a link differently. For every link, you must specify the permitted
transport systems of PrT and PuT (which are allowed to use the link). This means, that you can
close one of the directions to any traffic and model a one-way road in this way.

40

PTV AG

Chapter 2.1: Network objects

2.1.3.1

Link types

Visum describes the traffic-related properties of links with link attributes. It also offers the
possibility of dividing links with the same properties into 100 link types, which themselves have
attributes. Each link belongs to a link type via its attribute Type number. The 00 to 99 link types
serve as network classifiers and make it possible to assign type-specific standard values for
the following link attributes.

List of permitted transport systems on a link


Capacity PrT
Permitted free flow PrT speed (v0 PrT)
Minimum speed
Number of lanes
Rank of identification of the link rating
Permitted maximum speed vMax-TSys of every PrT transport system
Transport system-specific speed in PrT for toll
Transport system-specific speed v-PuTSys for the calculation of transport system-specific
PuT run times t-PuT from the link lengths
Three cost rates per transport system in PuT for the calculation of link costs within (see
"Calculation of the operating costs" on page 623) the operator model

In principle, the values of the attribute of a link of the assigned link type, is independent. This
means, that you can attribute each link independent of the link type. However, it is
recommended to apply exactly those values of the link type in the link. This is how you will
achieve as consistent as possible modeling of links and modifications to attributes can be
made more easily, because you can change these in the link type and then apply these to the
links (see User Manual, Chpt. 2.14.2, page 276).
For the assignment, each link type can be assigned a capacity restraint function, which thus
applies for all links of this link type (see "Impedance and VD functions" on page 216). This
allows you to apply a different mathematical correlation for the calculation of impedance on non
built up rural roads and built up urban roads.

Major flows
From the rank of the link types of the link which flow into a node, Visum determines a flow
hierarchy with a major flow. This always refers to two different link orientations (see "Network
objects of the junction model" on page 79). The major flow is taken from one of the three
criteria (see "Turn standards" on page 39) to determine the time penalties for the exiting
turning processes from the major flow or from another link. If possible, it should correspond to
the right of way or movement, advantaged through the SC. With this the rank of the link types
indirectly influences the result of the PrT assignment. The illustration 12 shows an example of
determining the flow hierarchy and particularly the major flows.

PTV AG

41

Chapter 2: Network model

Illustration 12: Rank of the link type and its resulting major flows (yellow), flow hierarchy (red)

Note: In the PuT model, the rank has no influence on the assignment result.

2.1.3.2

Permitted transport systems

The permitted transport systems specify the configuration of a link. The following types can, for
example, occur:

a simple road which can be used by PrT-vehicles and street-bound PuT


a rail track which can only be used by trains (trains, subways)
a road with tramlines
a one-way road which can only be traversed in one direction
a transfer walk link between PuT-stops

The illustration 13 shows three examples for permitted transport systems on different types of
links.

42

PTV AG

Chapter 2.1: Network objects

Car
Car

HGV
HGV

Bus
Bus

Tram
Tram

PuT-Walk
PuT-Walk

Car
Car

HGV
HGV

Bus
Bus

Tram
Tram

PuT-Walk
PuT-Walk

Car
Car

HGV
HGV

Bus
Bus

Tram
Tram

PuT-Walk
PuT-Walk

Road with tram lines

Car
Car

HGV
HGV

Bus
Bus

Tram
Tram

PuT-Walk
PuT-Walk

Car
Car

HGV
HGV

Bus
Bus

Tram
Tram

PuT-Walk
PuT-Walk

One-way road without tram lines

Car
Car

HGV
HGV

Bus
Bus

Tram
Tram

PuT-Walk
PuT-Walk

Transfer walk link

Illustration 13: Examples for defining transport systems of a link

The number of the lanes of a link is entered as an attribute, but also has to be considered for
the capacity (this means that the entered capacity does not refer to one lane, but to all lanes).
A link is always meant for both directions. In order to define a one-way road, close the opposite
direction to all transport systems.

Links which are open to PrT transport systems are taken into account during private
transport assignment.
Links which are open to PuT transport systems are taken into account during the
construction of line routes for public transport lines. PuT assignments (headway-based
or timetable-based procedures) are not based on link data, but on PuT line timetables.

To model passenger transfers between certain public transport stops, a special public
transport system PuTWalk may be introduced. These links are taken into consideration for PuT
assignments.

2.1.3.3

PrT capacity, PrT speed and PrT travel time

If there is free traffic flow in an unloaded network, the travel time t0 of a link can be determined
from the link length and the free flow speed v0.

Input: Length L [m]


Input: Free flow speed, v0 [km/h]
Result: Free flow travel time for t0 [s] = L 3.6 / v0

The free flow speed v0-TSys of vehicles of a particular transport system can be lower than the
free flow speed v0 of a link, because special speed limits might apply to these vehicles or
because the vehicles cannot drive faster. The maximum speed of a PrT transport system
vMax-TSys is an attribute of the link type.
Therefore, for speed v0-TSys and travel time t0-TSys applies:

PTV AG

v0-TSys = MIN (v0, vMax-TSys)


t0-TSys = L 3.6 / v0-TSys

43

Chapter 2: Network model

In a loaded network, travel time of a link is determined through a so-called volume-delay


function (also known as capacity restraint function) which describes the correlation between
the current traffic volume q and the capacity qmax. The result of the VD function is the travel time
in the loaded network tcur.

Input: Free flow travel time t0 [s]


Input: Traffic volume q [car units/time interval]
Input: Capacity qmax [car units/time interval]

Input: VD function, for example BPR function from U.S. Bureau of Public Roads
Result: Current in-vehicle time in the loaded network, for example
b
q
t cur = t 0 1 + a ------------------ (dependent on VD function type)
q max c

Result: Current travel time of a T-Sys = MAX (tcur, t0-TSys)

The illustration 14 illustrates how speeds vcur of two PrT transport systems develop depending
on the volume.
Link type Motorway
vmax (car) = 150 km/h

Link
v0 = 130 km/h

130

100

Car

HGV

vmax (HGV) = 100 km/h


Free traffic flow
vcur (car) = 130 km/h
vcur (HGV) = 100 km/h
partially linked traffic flow
vcur (car) = 110 km/h
vcur (HGV) = 100 km/h
linked traffic flow
vcur (car) = 80 km/h
vcur (HGV) = 80 km/h
Illustration 14: Example for the different speeds of two PrT transport systems depending on the volume

2.1.3.4

PuT run time

With every link, a PuT run time is stored for each PuT transport system. When inserting a link,
this run time is automatically calculated from the link length and the link type specific speed of
the PuT transport system. From the PuT run times of the traversed links the run time between
the stop points is then calculated when constructing a line route. This run time is in the
respective time profile (see "Specifications of lengths and times" on page 63).

44

PTV AG

Chapter 2.1: Network objects

2.1.4

Zones
Zones (also traffic cells) are the origins and destinations of movements (demand). This means
that each trip starts in a zone and ends in another zone. Zones connect the transport supply
(network model with nodes, links, PuT lines, etc.) and the travel demand (in form of demand
matrices (see "Matrices" on page 120)), which contain the demand (trips) of all OD pairs of the
model.
Every zone can be assigned a zone boundary (zone polygon) which represents the spatial
extension of the zone. In the network model, zones are reduced to a zone centroid. Here the
trips of a demand matrix are fed into the network. Every zone must be connected via a
connector (see "OD pairs" on page 46) to at least one node. The optional zone polygon has no
influence on the calculation results in the assignment; however, typical GIS functions such as
intersecting can be realized with the zone polygon (see "Intersect" on page 677). Multiple
zones can also be combined to a main zone for evaluation purposes.
The zone size can vary depending on the level of detail of the model. Zones generally describe
the position of places or utilities (for example, residential areas, work places, shopping centers,
schools). Structural data such as the number of inhabitants, the number of jobs or the number
of school places are stored here, which are used for calculating the traffic demand as input
data (see "Demand modeling procedures" on page 125).
The illustration 15 shows an example of the transport demand between the zones and how
they are available in the demand matrix.

Illustration 15: Transportation demand between zones illustrated in the transport network and as a demand
matrix

Note: Zone boundaries are managed (see "The surface data model in Visum" on page 111)
like surfaces and can consist of multi-face polygons and polygons with holes.

PTV AG

45

Chapter 2: Network model

2.1.5

OD pairs
OD pairs exist between all zones of the network. The values in skim matrices and demand
matrices (see "Matrices" on page 120) refer to one OD pair each. Compared to the other
network objects, you cannot edit OD pairs interactively in the network editor, but you can filter
OD pairs and display them graphically. For each OD pair you can select the skim matrix values,
the demand matrix values and the direct distance as attributes. The table 9 shows a demand
matrix value for Matrix 1 X and the skim matrix values for the skim of mean travel time for all
OD pairs in the example Example.ver.
From zone

To zone

100

100

Demand matrix value (1 X)


0.00

Skim matrix value (JRT)

100

200

2,000.00

38.00

100

201

200.00

12.00

0.00

100

202

0.00

32.00

200

100

2,000.00

38.00

200

200

0.00

0.00

200

201

5,000.00

16.00

200

202

2,000.00

13.00

201

100

200.00

12.00

201

200

5,000.00

16.00

201

201

0.00

0.00

201

202

0.00

20.00

202

100

0.00

32.00

202

200

2,000.00

13.00

202

201

0.00

20.00

202

202

0.00

0.00

Table 9: OD pairs in the example Example.ver

2.1.6

Connectors
Connectors connect zones to the link network. Each zone has to be connected to at least one
origin zone and one destination connector to the network for the assignment, so that the road
users can exit and enter this zone. A zone can be connected to the network with any number
of connector nodes.
A connector corresponds to an access or egress route between the zone centroid and the
connecting node. A connector has therefore two directions.

46

Origin connector from zone to node


Illustrates the access route to the network and thus the first part of the change of location.
Destination connector from node to zone
Illustrates the egress route from the network and therefore the last part of the change of
location.

PTV AG

Chapter 2.1: Network objects

The illustration 16 shows an example of how the travel demand between the zones, which is
saved in the demand matrix, is applied via the connectors to the network.

Illustration 16: Supply of the travel demand via connectors to the network

For each direction, the permitted transport systems, meaning those transport systems which
are permitted to use this connector, can be determined. In PrT, connections can be opened for
all PrT transport systems. In PuT, however, a path always starts and ends with a route traveled
by PuT pedestrian transit system on the connection. It is therefore assumed, that the access
and egress of the stop is always by foot. For connectors in PuT there are basically two
possibilities of modeling.

One or more nodes in proximity to the zone centroid are connected. A PuT path always
starts and ends with a walk link on the connector and continues on the network links to the
access nodes of the next stop area and from there to the stop point, from which a vehicle
journey is used (this approach is not recommended).
Only nodes which are also access nodes of a stop area are connected. In this case, each
path starts and ends with a walk link on the connector and within the stop continues to the
start stop point. Links are not used like that (this procedure is recommended).

The transport system dependent Connector time in unloaded network t0 is the time which
each transport system requires to pass the connector. The standard value for t0 per transport
system is calculated from the connector length (standard value is the direct distance) and the
connector speed which also exists as a standard value (see User Manual, Chpt. 2.18.1,
page 329). The standard value for the connector speed can be assigned separately for PuT
and PrT connectors. t0 can be overwritten manually by the user.

2.1.6.1

Distribution of demand of a zone to the connectors

For modeling connectors in PuT and PrT, there are different possibilities of influencing the
distribution of a zone demand to the connectors (see "Distribution of the traffic demand to PrT
connectors" on page 291 and "Distribution of the travel demand to PuT connectors" on
page 448). The illustration 17 provides an overview of these possibilities and describes each
effect.

PTV AG

47

Chapter 2: Network model

Illustration 17: Possibilities for modeling connectors

2.1.7

Main nodes and main turns


Any number of nodes can be incorporated in a main node. Main nodes can be used if the
Visum network is strongly disaggregated.
Main turns are constituent parts of main nodes. They are created automatically when a main
node is defined.

2.1.7.1

Main node

For the illustration of roads and other transport-related areas, which are more or less structured
by central reservation or traffic islands, there are several possibilities of displaying these in a
transport model. For relatively strong abstraction, the correlation of components with regard to
content, for example lanes of both directions on a road are illustrated by an individual link. This
is the best view for traffic engineering analyses. With the increasing application of navigation
networks with disaggregated illustrations of reality as a basis for transportation models,
networks divided into small sections play an increasing role. These models then have both lane
directions as two separated links in the Visum model. However, combining these in an
aggregated display would create a lot of work as well as a loss of information, because the
existing refined distribution is required when carrying out micro-simulations with the microsimulation program Vissim.

48

PTV AG

Chapter 2.1: Network objects

For conventional modeling, there is a contradiction between the activated demand for
disaggregated network display and that of differentiated turn delays per turn type. We want to
make it clear using an example.

Illustration 18: Intersection area with multiple nodes

If two roads intersect as in illustration 18 with separated lanes, the intersection area splits up
into four nodes. If a triangle island is also present, the turns with the respective node are also
added. A road user who comes from the bottom of the image and turns left, successively
passes nodes 1 to 5. Only at node 3 he follows a turn, which constitutes a left turn; all other
nodes he passes straight. Right turns only meet two nodes, at both nodes they traverse a turn
to the right, whereas straight paths pass four nodes. If turn penalties were assigned, the sum
of all traversed turns effects the node, although the contained shares, such as waiting at a SC
only once has an effect in reality. A possible solution could be, to individually set the turn times
of each movement, so that the sum of all traversing turns results in the desired value for the
movement. This, however, is not possible with a type-based allocation of values, because
turns of the same type would have to be attributed differently at the same node. There should
rather be a linear equation system for each intersection area.
The main node puts the thought underlying such a solution into effect by incorporating the
nodes belonging to an intersection area explicitly in a separate object. All nodes of the
intersection area thus form a logic unit, which takes the place of the previous nodes. Turns are
regarded on the logic level of the main node and are called main turns here.
Links whose From node and To node belong to the same main node are called inner links of
the main node. It is called a cordon link if only one of the nodes is part of the main node. These
constitute the access to and egress of main node: Each OD pair accesses the main node via
a cordon link and egresses it via another one. A link is also a cordon link, if both nodes are
allocated to different main nodes.
The combination of several nodes in a main node defines, based on the nodes of the main
nodes, different kinds of links:

Inner links: From node and To node belong to the main node (illustration 19: (1)).
Cordon links: one of the two nodes belongs to the main node, the other one lies
outside of it (illustration 19: (2)).
Directed links or One-way streets: this is a link with at least one direction with an
empty TSys set or zero lanes.

There is also cohesion between main nodes and different node types:

PTV AG

Inner nodes: only inner links originate here (illustration 19: (3)).

49

Chapter 2: Network model

Cordon nodes at least one cordon link originates here, additionally possibly inner links
(illustration 19: (4)).
Partial nodes: any nodes that are allocated to a main node. These could be inner
nodes, cordon nodes, and nodes lying beyond the boundary of the main node.
2

4
1
3

Illustration 19: Node and link types of main nodes

Note: Main node polygons are managed like surfaces and can be made up of multi-face
polygons or polygons with "holes" (see "Multi-part surfaces" on page 114).

2.1.7.2

Main turns

Main turns are constituent parts of main nodes. They are created automatically when defining
a main node and can be edited manually.
Main turns possess the same attributes as turns. They are automatically inserted or deleted
when editing cordon links, i.e. when inserting or deleting cordon links and when editing the
allocations to main nodes or relevant attributes (TSysSet, NumLanes).
Each movement via the main node is represented by a main turn. A main turn is therefore the
transfer from one cordon link to another. If the main node consists of a single node only, the
main turn corresponds to exactly the turn between the links concerned. It is thus a
generalization of the usual turns at a node on the level of the main node.
If we reconsider the intersection area in illustration 18, assuming that all displayed nodes were
incorporated in a main node, seven cordon links exist. Since a main turn leads from each
cordon link to each cordon link, there are 49 main turns at this main node. However, it does not
make sense to traverse some of them, as they enter one-way roads in opposite directions (see
"Main turns not open to traffic" on page 51). Exactly the 16 (or 12, in case of closed U-turns)
convenient movements via the main node remain the main turns that are open to traffic (see
"Main turns open to traffic" on page 51).

50

PTV AG

Chapter 2.1: Network objects

Illustration 20: Main turns open to traffic

Illustration 21: Main turns not open to traffic

Within a main node the main turn completely takes the place of the network. This means that
all traffic-related properties which take effect when crossing the main node are described
exclusively by the attributes of the main turn and the main node. A path that crosses the main
node only uses the main turn between the incoming and the outgoing cordon link. Neither the
attributes of the (inner) links, nodes and turns in between are evaluated, nor will these network
objects be loaded during assignment.

2.1.8

Main zones and main OD pairs


Any number of zones may be combined to form a main zone. The zones themselves remain.
There are OD pairs between all main zones of the network. The zone matrices (demand
matrices and skim matrices) can be aggregated to main zone matrices if desired. Likewise,
main zones can be broken down to zones. The same function is available for main zone
matrices, as for zone matrices. As an option, main zone boundaries (polygons) can be defined.
Note: Main zone boundaries are managed (see "The surface data model in Visum" on
page 111) like surfaces and can be made up of multi-face polygons or polygons with "holes".
Use cases for the application of main zones arise in the following situations:

PTV AG

Multiple zones can be aggregated to larger study areas in very detailed modeled networks.
This often also makes the graphical display in the network editor clearer.
Display of flow bundles on main zone level

51

Chapter 2: Network model

Display of desire lines


If you connect multiple zones to one main zone, you can make the desire lines clearer.
Executing diverse procedures on main zone level

Note: It is currently not possible to calculate assignments or demand models on main zone
level.

2.1.9

Territories
Local authorities such as counties or districts can be displayed as territories, for example. PrT
and PuT attributes can be calculated precisely by inserting territories and applying the
operations territorial indicators (see User Manual, Chpt. 4.4.3, page 970) and PuT operating
indicators (see User Manual, Chpt. 7.3.1, page 1219). This means, that the indicator share is
calculated which applies to a territory. Use cases occur especially when calculating PuT
operating indicators.
Note: Zone boundaries are managed (see "The surface data model in Visum" on page 111)
like surfaces and can be made up of multi-face polygons or polygons with "holes".

2.1.10

Paths
All assignments in Visum in PrT as well as in PuT are path based, meaning that possible paths
in the assignment are calculated for each origin-destination relation and loaded with a demand
share. All other results, especially the volumes of the different network objects and the skim
matrices are derived from these loaded paths. Paths are therefore the central result of the
assignment procedure.
In Visum the definitions path (PrT path and PuT path), PuT path leg and PrT paths on link level
are used. PuT paths are thus described with a sequence of PuT path legs. Link-based PrT
paths display all links which lie on a PrT path.
On the basis of assignment results, using paths you can execute detailed evaluations, such as
flow bundles (see "Flow bundles" on page 697), or verify the assignment results. As an option,
Visum saves the assignment of paths found (see User Manual, Chpt. 5.1.2, page 975).

Editing paths in PrT (PrT path object)


In PrT, the user can manually edit paths. New paths can be inserted and existing paths can be
modified. Both the course of PrT paths and their volume can be modified by the user (see User
Manual, Chpt. 2.23.7, page 388). These paths are also available in the usual procedure (such
as ICA or flow bundle calculations) like those paths created by a Visum assignment.
Beforehand however, they have to be converted into demand segment paths, using the
procedure convert paths. Furthermore, multiple so-called path sets can be maintained parallel
in a network. Path sets thus combine multiple paths to a group. This is how you can
successively store and switch between these assignment results in the network, for example.
The following use cases occur, editing paths manually:

52

Creating an own assignment result either by creating a network file in a text editor or
interactively by digitalizing paths.
Editing assignment results calculated by Visum. This may occur interactively by digitalizing
the path course in the network editor or by editing the path volume in the path list. On the
other hand, the paths can be written as network files and edited in a text editor.
PTV AG

Chapter 2.1: Network objects

Maintaining different assignment results in a network as path sets. Each path set then
contains the paths in an assignment.
Maintaining different flow bundle results as path sets. Each path set then contains the
result (the paths) of one flow bundle calculation.
Overwriting a selected section of the assignment result with external data. This is how only
paths which start in this planned residential area can be edited manually and the rest of the
assignment maintained in a transportation analysis.
Distributing a matrix on paths. For a given matrix and given paths, the matrix values are
distributed to the paths. This enables you to replicate the trip distribution and quickly update
the manual assignment.

There are two procedures for handling PrT path objects, which can be integrated into
calculation processes (see User Manual, Chpt. 2.23, page 380):

Converting paths (see User Manual, Chpt. 2.23.12, page 394). The procedure can be used
for example, to replace one assignment result with another. There are the following
possibilities:
Converting assignment result to path set
Converting path set to assignment result
Converting path set to path set
Converting assignment result to assignment result
Distributing a matrix to paths (see User Manual, Chpt. 2.23.14, page 396). Based on a
matrix and paths, the trips of the matrix are distributed to the paths. This enables you to
modify the demand on the level of OD pairs and then distribute the new demand to all
existing paths of the OD pair, in proportion to the previous shares. Distribution is carried out
with the attribute ShareOfPathTarget. The attribute can be defined for each path by the
user. For each OD pair of a path set the attribute ShareOfPathTarget is first added up
(total weight) on all paths.
P

Total weight =

i = 1 ShareOfPathTarget

Where P is all paths in a path set of origin O to destination D. If e.g. there are five paths
from zone A to zone B, the ShareOfPathTarget of the five zones is added together.
The volume of an individual path p then results from the following equation.
p.ShareOfPathTarget
p.Load = Matrix value --------------------------------------------------------Total weight

PTV AG

53

Chapter 2: Network model

2.1.11

Stop hierarchy: Stops, stop areas, stop points


In the PuT sector there are a variety of stops, which extremely differ in construction and size.
This variety can range from simple masts by the roadside to large, multi-story railroad stations,
bus terminal or subways. Compared to this, there is a concept in Visum, which also allows
large stations to be illustrated in detail and also comprehend simpler situations, without having
to specify many entries. This illustration is shown in Visum, by the so-called stop area
hierarchy, which is composed of the network objects stop, stop area and stop point. Each of
these three levels fulfills certain, clearly separated tasks within the transport network.

Stop point
Specified departure point for one or more lines. PuT lines stop here for passenger
boarding. In the most detailed model, the stop point corresponds to a stop sign for bus
services or the edge of a platform in the case of rail services.
Stop area
Combines several stop points in close proximity and displays the access to the stop points
in the remaining transport network via an access node.
Stop
Is the object which comprises the entire complex of stop points and stop areas. It is the
highest object of the stop hierarchy and carries the name of the stop and others, for the
entire construction applying attribute. In the real network, it is therefore of more
organizational nature.

Stop point
at link 1-2
after 50 m

Stop area

H
1

H
Stop

Illustration 22: The stop hierarchy

2.1.11.1 Stop points


Because the vehicles can only move within the modeled network, a stop point has to be
connected to the network. This is achieved, by either inserting a stop point on a link or on a
node. If a stop point is on a link, it is called a link stop point. A stop point on a node can be
supplied by all lines which traverse this node. A stop point on a link can only be served by lines
which pass this link. This permits detailed direction modeling based on masts. Stop point links
can, however, also be inserted undirected, so that they can be run for both directions of the
link.

54

PTV AG

Chapter 2.1: Network objects

Undirected
stop point on link

H
Directed
stop point on link

Stop point on node

Link stop points


Illustration 23: Possibilities of modeling stop points

The differentiation between stop points on nodes and links allows network models of different
levels of detail to be generated with Visum:

For strategic planning, stop points on nodes are sufficient, since the exact position of the
stop point in front of or behind the road junction is usually of no interest. The stop area
and stop are generated automatically in the background, but generally remain hidden to the
user, if desired.
For operational planning and AVLS supply, it is useful to model the stop points on links, as
you can then achieve the required degree of detail.

It is also possible, of course, to mix both types in Visum, for example by using the more
accurate link-based model in built-up areas and the node-based model in non-built-up areas.
A stop point can be permitted or blocked for each existing transport system. Only line route
vehicle journeys, whose transport system is permitted, can stop there.
Notes: We recommend to set the start or end point of a line route only at stop points which
are located on nodes, because inaccurate results might occur if a line route starts or ends at
link stop points, for example, when calculating PuT operational indicators or in case of PuT
volumes which are displayed on link level.
Because vehicle journey stops always occur at a stop point, each stop has to have at least
one stop point.

2.1.11.2 Stop areas


A stop area divides a stop into areas. An area can for example represent a bus or train station
platform, an intersection with stop points, a P&R car park, a station concourse, etc. A stop area
is assigned to a single stop and can comprise several stop points.
Stop areas are used on the one hand to determine transfer walk times between the stop areas
of a stop. They combine stop points which do not differ from other stop points with respect to
their transfer walk times. If for example at a railway station the stop points of the individual
platforms are combined into a single stop area and the bus stops on the forecourt as well, this
makes it possible to include closely separated minimum transfer times from rail to rail, rail to
bus, and bus to bus. The matrix of transfer walk times (From Stop Area To Stop Area) can
indicate which public transport walk system (for example, stairs, escalator, lift, ground-level

PTV AG

55

Chapter 2: Network model

walkway) is used. The transfer time for a demand segment is always the minimum time
required for all permitted PuTWalk systems. User group-dependent transfer times, for example
for mobility-impaired persons, can be modeled by permitting selected PuTWalk systems (for
example, ground-level walkways and lifts) only for specific demand segments. Stop areas can
also represent intermediary levels in large station areas. In this case, while transfer times to
other stop areas exist, the stop area itself does not contain stop points.
Note: The transfer walk times (transfer walk times matrix) between the stop areas is defined
at the stop.
The second function of stop areas is to connect stops to zones and the walkway network
beyond the stop. As an option, to each stop area a network node which can be reached with
the same transfer times like each stop point of the area can be allocated. The time within a stop
area (diagonal of the transition matrix) is not used for the transfer to the access node. Via this
network node, PuT paths can change from a public transport line to links with PuTWalk or PuTAux transport systems as well as to connections to zones and vice versa.

2.1.11.3 Stops
A stop comprises the entire complex of stop areas and thus also stop points. To ensure that a
stop can be localized and displayed in graphical form, it has a coordinate, but it is not assigned
directly to a network node or link.
The stop contains information on route times within each stop area (on the transfer walk time
matrix diagonal) and between two stop areas. In addition to these walk times, as an option the
stop also has transfer walk times and wait times between transport systems. With this a
particularly through structural or organizational measures aggrieved or favored transfer
between vehicle journeys can be illustrated, for a modeled stop without stop areas, for
example. The general transfer walk time of eight minutes could apply in a large train station,
when changing from an ICE train to another train, however, because of track information, three
minutes should be sufficient, for example. In such a case, these three minutes could be defined
as transfer time of the transport system ICE in the same transport system.

2.1.12

PuT operators
Providers of public transport vehicle journeys, for example local transport services or train
operating companies, are called operators. The network object operator is the starting point for
analyses of the public transport supply from operator point of view. It is therefore used within
the network for grouping lines and vehicle journeys to jointly evaluate units. An example is the
distribution of the revenues to the various operators of a transportation agency. This is often
based on service kilometers or seat kilometers. If you have assigned operators to the vehicle
journeys in your model, you can evaluate these and many other indicators (see "Operator
model PuT" on page 521).
Operators can either be assigned to a whole line (one then talks about a standard operator) or
individual vehicle journeys.
Note: Please note that changing the standard operator of a line subsequently, does not
overwrite the operators of existing vehicle journeys.

56

PTV AG

Chapter 2.1: Network objects

2.1.13

PuT vehicles: Vehicle units and vehicle combinations


In Visum, PuT vehicles such as buses, trams or intercity trains are modeled through the
network objects vehicle unit and vehicle combination. Using these network objects, it is
possible to change the composition of a vehicle journey en route (see "Network objects of the
line hierarchy" on page 58). This is how a train in the preceding and succeeding legs can run
with fewer coaches than in the main leg. The second application case for PuT vehicles is in the
operator model section. Indicators such as service kilometers can be evaluated on the level of
vehicle combinations (see "Operator model PuT" on page 521).
Each vehicle unit is allocated to one or more transport systems. It can only be used for vehicle
journeys, lines or system routes, which belong to one of these transport systems. Furthermore,
for each vehicle it is specified whether it is a railcar or not. In addition to the number of seats
and the total capacity including also the standing capacity, cost rates can be entered per
distance and time unit, for vehicle journeys und empty trips separately. These data are
determined within the scope of the operator model for evaluations.
Vehicle units are combined to vehicle combinations. A vehicle combination thus always
comprises one or more vehicle units. The same vehicle unit can appear repeatedly in the
vehicle combination. This is how a vehicle combination intercity train can be composed of a
vehicle unit railcar and multiple vehicle units coaches, whereas for the railcar and the coaches
different cost rates or capacities can be specified.
The set of permitted transport systems for a vehicle combination is determined as a mean of
the permitted transport system sets of the respective vehicle units. If there is no transport
system permitted for all associated vehicle units, these cannot be combined to a vehicle
combination.
Also for vehicle combinations, separate distance and time related cost rates can be specified
for vehicle journeys and empty trips. These take effect together with the cost rates of the
respective vehicle units. Use these input possibilities therefore for such costs, which
accumulate only once per vehicle combination. Typically, maintenance costs should be
specified per vehicle unit, and personnel costs however, per vehicle combination.
Vehicle combinations can be assigned eitehr to entire lines or time profiles (one then talks
about a standard vehicle combination) or to individual vehicle journey sections. This enables
very detailed modeling of changes in train formations or also strongly disaggregated
evaluations of PuT operator indicators, for example.
Note: Please note that subsequent modifications of standard vehicle combinations of a line
or a vehicle profile do not overwrite the vehicle combinations of the existing vehicle journey
sections.

2.1.14

The line hierarchy


The modeling of the transport supply in PuT is hierarchical. This structure enables the user to
reuse data specified once as efficiently as possible, for example the course of a line for several
vehicle journeys.

PTV AG

57

Chapter 2: Network model

2.1.14.1 Network objects of the line hierarchy


The illustration 24 shows the six network objects of the line hierarchy.

Main line
Line
Line route
Time profile
Vehicle journey
Vehicle journey item
Illustration 24: The line hierarchy used to model the PuT supply

Main lines
This optional network object is used for an aggregated evaluation of the lines allocated to the
main line. A main line can also incorporate lines of different transport systems. The network
object does not affect the assignment or the structure of the timetable.

Lines
A line structures the public transport supply. Within the Visum data model, it is mainly used to
aggregate several line routes. Each line has at least one line route or multiple line routes. The
line itself neither has a spatial course in the network (see "Line routes" on page 58), nor are run
times specified between the stop points (see "Time profiles" on page 60). Each line belongs to
exactly one transport system. You can optionally allocate a standard operator and a standard
vehicle combination to a line. When creating new vehicle journeys, they will then be suggested
as default values.

Line routes
A line route is part of exactly one line and describes the Spatial route course of the line for
one direction (from now on called the Line route course).
The line route course is issued as a classified series of route points. The length data of the line
route course are output between two consecutive route points. A route point can be a node or
a stop point along the line route course. All stop points along the course at which the line route
can stop, are always route points. All nodes along the course can optionally be declared as
route points. The line route course must start and end at a stop point that is located on a node.
The line routes of a line are usually available in pairs for the two directions. However, each line
can incorporate any number of line routes (cf. for example illustration 25). Different line routes
(pairs) of a line represent different route courses, which are organized in lines.

58

PTV AG

Chapter 2.1: Network objects

Line routes can be generated either manually or based on existing system routes (see "System
routes" on page 70).
Link network

Line route 1

Line route 2

M
S

important route point for line


other stop point or node
Illustration 25: Example for two line routes of a line

PTV AG

59

Chapter 2: Network model

Time profiles
Each line route has one or more time profiles. A time profile describes the temporal sequence
of the line along the line route. However, specific departure times are not specified, but the run
times between the individual route points.
Analogous to the line route (route points), the time profile is described by a sequence of profile
points. This sequence of profile points is called the course of the time profile. Any route points
of the underlying line route can be profile points. However, the start stop point and the end stop
point of the line route as well as all stop points, at which passengers can board or alight must
be among them. The time profile may also contain passage times for any route points of the
line route, e.g. for a conflict check of the timetable routes. Profile points are the points in the
network, between which the run times are specified in the time profile. The run time is specified
for the section between the previous and the current profile point. In case of stop points, a stop
time can additionally be specified and boarding and alighting can be permitted or prohibited.
Multiple time profiles of a line route can, for example, differ in the selection of the profile points
or the run times on the different sections between the profile points (cf. for example
illustration 26). If a vehicle journey of a line route shall stop at a stop point along the route yet
another one shall not stop, you need to define two time profiles for the same line route (yet not
if a vehicle journey shall serve just a section of the line route and thus of the time profile).
Furthermore, each time profile has a name and an allocation to a direction. Optionally, a
standard vehicle combination can be allocated to the time profile. When inserting a new vehicle
journey, this is then applied automatically as a default value.
Note: Please note that the vehicle combinations of existing vehicle journeys are not
overwritten. If a standard vehicle combination is specified for the line also, the standard
vehicle combination of the time profile takes effect when inserting a new vehicle journey.
Fare points can still be specified at the time profile, for each profile point. These can enter the
calculation of revenues (see User Manual, Chpt. 7, page 1157).
When modeling public transport, time profiles are important in the following use cases:

Couplings are set on time profile level (see User Manual, Chpt. 2.31.5.5, page 483).
Headways for the headway-based assignment are specified on time profile level (see User
Manual, Chpt. 6.9, page 453).

As a consequence, all network objects which, in the line hierarchy are located below the time
profiles (vehicle journeys and vehicle journey sections), are not relevant when defining
headways or couplings. Therefore, if you want to couple profiles on vehicle journey level or
specify headways, you need to create a separate time profile for the respective vehicle
journeys and carry out the coupling or the definition of the headways here.

60

PTV AG

Chapter 2.1: Network objects

Line route 1

Time profile 1.1

SPoint

Stop

Time profile 1.2


Arr

Dep.

SPoint

Stop

0:00

Arr

Dep.

1:00

1:02

2:00

2:02

1:50

1:52

3:00

3:02

2:50

2:52

5:00

5:02

4:50

5:02

6:00

6:00

0:00

M
Illustration 26: Example of two time profiles of a line route

Vehicle journeys (=journeys)


A vehicle journey describes a planned public transport service or a set of planned service trips,
which are summarized to an administrative unit with a given ID number. Every day of the
calendar used in the network, at most one of these vehicle journeys will then run.
Each vehicle journey belongs to exactly one line route and exactly one time profile. It also has
a reference to two stop points of the line route, which define the section on which the vehicle
journey follows the course of the line route. Vehicle journeys can therefore traverse any section
of a line route. It is therefore not necessary to define a line route with a shorter extension for
vehicle journeys, which only traverse a line route partially. Vehicle journeys cannot, however,
switch from one line route to another. This means that each trip can only run on exactly one
line route.

PTV AG

61

Chapter 2: Network model

Furthermore, the vehicle journey contains a departure time at the start stop point from which,
together with the relative times of the time profile, all arrival, departure and non-stop run times
of the vehicle journey are determined.
A vehicle journey can optionally be assigned an operator. You can then calculate aggregated
evaluations of PuT operating indicators on operator level (see "Operator model PuT" on
page 521).

Vehicle journey sections (=journey sections)


There is normally exactly one journey section per vehicle journey. This is created automatically
when inserting a vehicle journey. As an option, a vehicle journey can be subdivided into
multiple vehicle journey sections, which can then be divided into the following properties.

Valid day
Vehicle combination
Start and end stop point
Pre and post preparation time for line blocking (see "Line blocking" on page 532)

This results in the following application possibilities for example.

A vehicle journey, which traverses from A to C via B from Monday to Friday, on the
weekend however, only from A to B, can be modeled by two vehicle journey sections, which
only differ in their valid days.
A train, running from A via B to C, between A and B however with less coaches, can be
modeled by two vehicle journey sections, which differ in their vehicle combinations and
start and end stop points.
Any combinations are possible, for example a train which runs between A and B and which
is only short on the weekend.
Vehicle journey sections are network objects, with which line blocking is carried out (see
"Line blocking" on page 532).

The table 10 shows an example with three vehicle journeys of a line route. The line route has
two time profiles. Vehicle journey 993 is divided into three vehicle journey sections, which differ
in valid days and vehicle combinations.

62

Trip number

from -> to

Departure time

Valid day

Vehicle combination

991

NH

06:02 a.m. (daily)

Daily

Loco + 6 coaches

992

MH

05:10 a.m. (daily)

Daily

Loco + 6 coaches

993

MH

06:00 a.m. (daily)

Daily

Loco + 6 coaches

HS

11:02 a.m.
(Sat+Sun)

Sat+Sun

Loco + 6 coaches

MN

06:00 a.m. (Mon-Fri) Mon-Fri

1 additional coach

PTV AG

Chapter 2.1: Network objects

Line
Line route
Time profile

IC1

IC1

1.1

1.2

1.1

Trip number

991

992

Valid day

Daily

Daily

Vehicle combination

L+6C
-

M dep.

IC1

993
-

Mon-Fri

Sat+Sun

Mon-Fri

L+6C

L+6C

L+6C

1C

5:10

6:00

I arr.

07:00 a.m.

I dep.

07:02 a.m.

07:00 a.m. 08:00 a.m.

06:02 a.m. 07:02 a.m. 08:02 a.m.

N arr.
N dep.

W arr.

07:00 a.m. 08:00 a.m. 09:00 a.m.

W dep.

07:02 a.m. 08:02 a.m. 09:02 a.m.

H arr.

09:00 a.m. 10:00 a.m. 11:00 a.m.

H dep.

11:02 a.m.

S arr.

12:00 a.m.

Trip number 991 requires one vehicle journey section


Trip number 992 requires one vehicle journey section
Trip number 993 requires three vehicle journey sections
Table 10: Example of three vehicle journeys

2.1.14.2 Specifications of lengths and times


In conjunction with lengths, different attributes exist at different network objects. The
illustration 27 displays these attributes and their correlations. The attribute Length at the link
is used as standard value for the attribute PostLength at the line route items. The user has the
possibility of overwriting these standard values. This can be done manually, for example in the
list for line route items (see User Manual, Chpt. 12.1.10, page 1386). If the standard value from
the link lengths should be carried out, you can use the function set lengths. There are four
possibilities for changing the link length.

PTV AG

The link length can be allocated from the direct distance of the link (see User Manual, Chpt.
2.14, page 276).
The link length can be allocated from the polygon length of the link (see User Manual, Chpt.
2.14, page 276).
When shaping the link, it can be specified that the link length should comply with the
polygon length (see User Manual, Chpt. 2.14.11, page 290).
You can overwrite the link length in the link list manually, for example, and thus assign any
length to the link (see User Manual, Chpt. 12.1.10, page 1386).

63

Chapter 2: Network model

Connection between lengths

Mulit-Edit Attribute: use Length DirDist

Link

Mulit-Edit Attribute: use Length Polygon

Length
When editing the shape of the link: Take over Length-Polygon
Manual overwriting

Standard

Line route items


Set lengths: uses the length of the link

To Length
Manual overwriting

Legend
Standard

The value of the attribute is used as standard value for another attribute. Please note: when subsequently
editing the attribute (e.g. t-PuTSys), the value is not adjusted automatically (for example for the Run time
at time profile). To do this, please use the suitable functionality on the right-hand side (such as Set
times: from link run time)

Illustration 27: Lengths in Visum and their coherence

Visum offers different possibilities to assign times to links and time profiles. The illustration 28
provides an overview on how you can influence the run time values for links and time profiles.
The standard values for the link run time of a PuT transport system (t-PuTSys) is calculated
from link length divided by the link-specific speed of the PuT transport system. The link run time
of the PuT transport system again provides the standard values for the travel times in the time
profile. The departures and arrivals of a vehicle journey always automatically result from the
times provided in the respective time profile. The run times for each PuT transport system can
be changed as follows.

The run times can be assigned from the line run times.
The standard value (quotient of link length and link-specific speed of the PuT transport
system) can be restored.
You can overwrite the times manually in the link list, for example (see User Manual, Chpt.
12.1.10, page 1386).

The run times of the time profile can be edited as follows.

64

Transferring the standard values from the link run time


Transferring the times from a system route
Transferring the times from a link attribute
Setting the times from a time profile attribute
You can overwrite the times manually in the time profile list, for example (see User Manual,
Chpt. 12.1.10, page 1386).

PTV AG

Chapter 2.1: Network objects

Allocation of run times


Link length
Link type-specific speed of the PuTSys
Standard

Link

Generating link run times from line run times

Link run time t-PuTSys

Standard values
Manual overwriting

Standard
Set times: from link run time

Time profile

Set times: from system route

run time

Set times: from link attribute


Set times: from time profile item attribute

Auto

Manual overwriting

Vehicle journey
Departure/ Arrival

Legend
Standard

Auto

The value of the attribute is used as standard value for another attribute. Please note: when editing the
attribute (for example t-PuTSys) afterwards, the value is not adjusted automatically (e.g. for the Run time
at time profile). To do this, please use the suitable functionality on the right-hand side (such as Set
times: from link run time)
For the temporal scheduling of the vehicle journeys, the times of the associated time profile are transferred
automatically. If you thus change a run time in the time profile, the time of the associated vehicle journeys
will be changed automatically.

Illustration 28: Assignment of run times in Visum

2.1.14.3 The term timetable in Visum


According to the line hierarchy the timetable in PuT in Visum is set up hierarchically. The line
route contains the information on the location, the time profile accounts for relative time
specifications and the vehicle journeys and their vehicle journey sections provide valid day,
departure time and the traversed sections of the line route. All four object types together make
up the timetable, therefore the information, where and when PuT vehicle journeys take place.
Alternatively, the public transport supply side can also be described through line routes, time
profiles and a regular service per time profile (see "Headway-based assignment" on
page 453). In this case we are also talking about a timetable in Visum.
Due to this hierarchical structure of the timetable, is it possible to reuse the data for various
similar vehicle journeys. Otherwise, the exact route in the network would have to be specified
for each individual vehicle journey and all times entered. With the line hierarchy however, a
regular headway can easily be defined by specifying the departure times, the time profile and
the line route.

PTV AG

65

Chapter 2: Network model

2.1.14.4 Data consistency along the line hierarchy


An important property of the line hierarchy is the consistency of the various data. Line route,
time profile and vehicle journey section must match at any point of time. A run time between
two stop points, which are not touched by the used line route, are never allowed to be specified
in the time profile. Visum assures that this consistency is always maintained. If you make
changes to the objects of the line route, the objects based on these may be adjusted, to
reestablish a consistent state applicable to the new situation.

2.1.14.5 Aggregation of line routes


Aggregation of line routes is the aggregation of several line routes or time profiles to combined
objects. A number of line routes with the same or similar information can occur especially when
importing old networks from Visum 8 or when importing timetable data from an external source.
In an extreme case, both an individual line route and a specific time profile are created for each
individual vehicle journey. Essential advantages of the hierarchical setup of the Visum PuT
model are thus lost, such as the reuse of line route data for many vehicle journeys.
Furthermore, the number of line routes makes editing and maintaining the overview more
difficult. The function aggregate line routes supports you when importing third-party data, to
use these to your advantage.

Criteria for aggregating line routes


When aggregating, two line routes are aggregated in the first step. Both line routes have to
have common line path sections, but do not have to necessarily correspond with each other. If
it has been determined, that two line routes can be aggregated successfully, the time profiles
of a line route are tried to be aggregated in a second step. The following general criteria for the
aggregation of line routes apply.
1. Both line routes have a common path leg.
2. The start of the common path leg is also the start of (at least) one of both line routes.
3. The end of the common path leg is also the end of (at least) one of both line routes.
The illustration 29 shows examples of cases in which aggregation is possible and in where not.

66

PTV AG

Chapter 2.1: Network objects

Line routes to be aggregated


A

Aggregated line routes


D

F
A

Violates criterion 2: The start of the path leg in


common is not the start of either line route
Aggregation not possible

Violates criterion 3: The end of the path leg in common


is not the end of either line route
Aggregation not possible

Violates criteria 2 and 3 Aggregation not possible

Illustration 29: Example of the aggregation of line routes

As an option, aggregating line routes can be made more difficult with the following conditions.

Line routes have to be assigned to the same line.


Line routes must have the same lengths on the common section.
Line routes must have the same direction.

Aggregating time profiles can also be made more difficult as an option.

Time profiles must have the same run and dwell times.
Time profiles must have the same settings for boarding and alighting.
Time profiles must have the same vehicle combination.

2.1.14.6 Coupling time profiles


Coupling means connecting cars of two or more trains on a line route section. The figure shows
several examples of coupling two or three line routes. If you want to link two line routes on a
section, the stop points of their time profiles must correspond to each other. Their run times
and stop times on the "linking" section, however, need not be identical. If required, they can be
changed.

PTV AG

67

Chapter 2: Network model

H1

L1-1

H4

H3

L1-2
L1-3

L1-1
H2

H1

H3

H2

H5

L1-2

H5

H4

H6

H3

L1-1

L1-1

H5

L1-2
L1-3
H1

H2

H4

H6

H1

H2

H3

H4

L1-2

Illustration 30: Examples: Coupling two and three line routes

The number of vehicle journeys and their departure times from From/To Stop Points of coupled
sections may deviate. Missing vehicle journeys are generated.
In Visum, coupled line routes form a coupling group. Visum adjusts the times and the timetable
of the coupled line routes. Visum automatically adjusts the data of all line routes of the coupling
group after changes to the time profile of a single coupled line route.

Changes to the number of vehicle journeys


Changes to the number of vehicle journeys on a coupled section may occur in the following
cases.

Inserting and deleting vehicle journeys (see User Manual, Chpt. 2.43, page 658)
Inserting and deleting vehicle journey sections (see User Manual, Chpt. 2.43, page 658)
Changing the length of vehicle journeys (see User Manual, Chpt. 2.43, page 658)

These changes need to have an effect on coupled time profiles, so that the supply of vehicle
journeys in each coupling section is synchronized again.

Changes to the temporal position of vehicle journeys


In the following cases, the temporal position of vehicle journeys may change. These changes
need to have an effect on coupled time profiles, so that the supply of vehicle journeys in each
coupling section is synchronized again.

68

In-vehicle time/stop time changes to the time profile


This has an effect on all vehicle journeys that include the section start item --> reference
point or reference point --> start item respectively in the altered section.
Changes to the departure time of one or more vehicle journeys via Edit vehicle journey in
the timetable editor, Multi-edit in the network editor or by shifting the vehicle journey within
the timetable editor.

PTV AG

Chapter 2.1: Network objects

Coupling when calculating the PuT operating indicators


Couplings in some cases have an effect on the calculation of PuT operating indicators (see
"Impact caused by couplings" on page 647). On which indicators exactly they have an effect
can be found in the file Indicator availability.xls in your Visum installation. The effect on
coupling is illustrated by some examples.

Service-km of the line route


The kilometers traversed by the coupling section are considered only once and distributed
to the coupled line routes. 50% of the length of the coupled route section is assigned to
each of the coupled line routes after coupling 2 line routes.
Service time of the line route
As for kilometers, the service time is only calculated once and distributed evenly.
Infrastructure cost of the line routes for links and stop points
Link costs (for example rail track cost) and stop point costs are considered only once.
These costs are distributed evenly to the coupled line routes.
The number of line services and vehicle kilometers per link are only counted once.

As service-km, service-time and the infrastructure cost influence the operating cost of a line
route, coupled line routes which result in lower costs.
Coupling does not have an impact on line blocking or assignments.
During assignment, changing seats within a coupled line is thus regarded as a regular transfer
between line routes.

40 km
30 min

50 km
30 min

40 km
30 min

H1

H4

L1-1
H3

H2
L1-2

H5

H6

40 km
30 min

50 km
30 min

40 km
40 min

Illustration 31: Calculation example for the calculation of indicators in case of couplings

PTV AG

69

Chapter 2: Network model

Number of trips

10 trips

Empty time

10 min/trip

Kilometer costs

1 euro/km

Hourly costs

60 euros/h

Track price

1 euro/km

Seats

100 seats/vehicle combination

Table 11: Input data for the calculation example


Not coupled

Not coupled

Coupled

Coupled

L1-1

L1-2

L1-1

L1-2

Line route
ServiceKm
SeatKm
Service time
Out-of-depot time

1,300 km

1,300 km

1,050 km

1,050 km

13,000 km

13,000 km

13,000 km

13,000 km

900 min

1,000 min

750 min

850 min

1,000 min

1,100 min

850 min

950 min

Cost

1,300 EUR

1,300 EUR

1,050 EUR

1,050 EUR

Cost

1,000 EUR

1,100 EUR

850 EUR

950 EUR

Track costs

1,300 EUR

1,300 EUR

1,050 EUR

1,050 EUR

Total cost

3,500 EUR

3,600 EUR

2,950 EUR

3,050 EUR

10

10

10

10

Num Vehicle
journeys

Table 12: Calculation of indicators for the line route


Link
ServiceKm
Num Vehicle
journeys

H2-H3

H3-H4

H2-H3

H3-H4

1,000 km

400 km

500 km

400 km

20

10

10

10

Table 13: Calculation of indicators for the links

2.1.15

System routes
A system route describes a route within the network from one stop point to another, with the
time required. As an option, this required travel time as well as supplements for starting and
braking per vehicle combination can be further specified. It is important that the travel times are
always stored independent of concrete lines in the system route. The system route thus
represents a time which a certain vehicle combination requires on a given route between two
stop points, independent of whether they belong to a line or even to a concrete vehicle journey.
This travel time and route information can be used in two ways for creating a timetable.

70

Editing the shape of a line route with system routes


Travel times of existing line routes and time profiles are composed of system routes

PTV AG

Chapter 2.1: Network objects

Editing the shape of a line route with system routes


System route path information provides a part of the line route path. The travel time information
goes into the upper travel time profile in sections. Alternatively, you can create line routes or
individual sections with system routes. As soon as there are successive system routes at the
current end point, these can be used to extend the line route to the end stop point of the system
route. The travel times for this section can be taken from the system route, preferably the one
for the correct vehicle combination, if this is specified. If both the start stop point and the end
stop point of the system route are served by the line route, the run time is determined as the
sum of the passage time and the TStartStop and TEndStop of the line route. If the line route
runs past one of the successive stop points, the share of the corresponding supplement is
omitted. In this way, it is possible to use system routes for stopping as well as for traversing
time profiles.

Setting travel times of existing line routes and time profiles


You can use system routes to reset run times of existing line routes and time profiles. The path
information of the line route is not lost. If a matching system route exists between two profile
points of the time profile, its run time will be used for the time profile. Depending on whether
passengers are scheduled to board and alight at the limiting stop points, only the pure passage
time or the sum of the passage time TStartStop and TEndStop will be used.
A system route matches a section between two profile points, if the following conditions apply.

Both profile points are located at stop points.


These stop points are start stop point and end stop point of the system route (this requires
that these stop points must be open to the transport system of the time profile).
The course of the line route underlying the time profile is identical to the course of the
system route.
The transport system of the system route is identical to the one of the time profile (i.e. the
line).
If the respective option has been selected, at the system route, a specific run time must be
specified for the vehicle combination allocated to the time profile or line.

If several matching system routes exist, the times are not set for the sections in question.
When new time profiles are created, the run times are calculated on the basis of the system
route (if available). Special defaults are taken into account for the vehicle combination if it is
specified for both the system route and the time profile.
If no system routes have been defined, link times are used as before.
Besides being used in the timetable, system routes play an important role in line blocking. As
an option, system routes can be used for empty trips within line blocking or new system routes
can be generated automatically for that purpose (see User Manual, Chpt. 2.33.8, page 527).

PTV AG

71

Chapter 2: Network model

2.1.16

Points of Interest (POI)


A Point of Interest (POI) is a user-defined network object with spatial reference. The spatial
reference is established by entering an X and a Y coordinate for each POI. POIs can be
inserted as point or surface objects. Each POI can be assigned a surface (attribute Surface ID)
as an option or any image (attribute Image file name). By default, Visum already offers a
preselection of symbols, which can be used for visualizing POIs (star, cross, triangle, SC, and
others).
Note: POI polygons are managed like surfaces and can be made up of multi-face polygons
or polygons with "holes" (see "The surface data model in Visum" on page 111).
Points of interest are mainly used for data management (for example, network data
maintenance in Traffic management centers) and accessibility studies. For your data
management, you can create as many user-defined attributes for POIs as you like, in which
you can store your data (see "User-defined attributes" on page 101). The illustration 32 shows
an example for applying POIs in reachability analyses. Here secondary schools are included
as POIs (red stars) in the model. The catchment area of these schools was visualized with the
2D display (see "2D display" on page 752).

Illustration 32: Reachability analyses for secondary schools

72

PTV AG

Chapter 2.1: Network objects

POIs are managed in POI categories. Each POI must be allocated to a POI category. Before
inserting the first POI, you thus have to create a POI category (see User Manual, Chpt. 2.34.1,
page 532). Any number of POI objects can then be inserted in the defined POI category, in the
network.
POI categories in a transport network are for example

Parking and Park&Ride facilities


Public facilities such as schools, churches of hospitals
Pre-emption points for AVLS (automatic vehicle location systems)
SC controllers etc.

POI categories can be organized as a hierarchy. This is how you can create a POI category
schools with the three subcategories secondary schools, junior high schools and elementary
schools.
Each POI can be assigned to a node, a link, another POI, a stop area, a stop point or a POI
category. You can illustrate this assignment graphically in the network (see User Manual, Chpt.
12.3.5, page 1411). In the example of illustration 33 allocations are used to illustrate for
parking lots in a downtown area which links the approaches lead to.

Illustration 33: Allocating POIs to links

If you want to import data from GIS systems into Visum, these data can be stored as POIs in
the network model (see User Manual, Chpt. 10.4, page 1295).

PTV AG

73

Chapter 2: Network model

Notes: POIs and their assignment to network objects do not have an influence on procedures,
such as assignments for example.
If you create a user-defined attribute for a POI category, it will also be created for all
subcategories of the POI category.

2.1.17

Count locations and detectors


Count locations mark the geographical position of traffic counts. This can be both one-off
counts and permanently installed counting features. A count location is identified by a number.
Apart from a code and a name, it always has a position on a link, described by the ID of the link
(From Node and To Node) as well as a relative position. This is a number between 0.0 and 1.0
and describes where the count location lies on the link. Since a link in Visum is always directed,
a direction is indicated as well. Furthermore, the count location has a type, to differentiate
permanent count locations and manual count locations, for example. The coordinates of the
count location are available as a calculated attribute; these are calculated from the coordinates
of the link and the position along this link. Each link can be assigned by direction to one or more
count locations. Each count location can in turn be assigned to detectors.
The detector is identified by its number and in addition to code and name it has a geographic
position, specified by a pair of coordinates. Two types of detectors are distinguished:

The detector is allocated to a node or a main node. This type of detector serves for
modeling signal control, for example, traffic-responsive signal control. It is not possible to
define a reference to count locations.
The detector is defined freely in the network and as an option, it can be allocated to a count
location, and so also indirectly to a link. In this case the detector constitutes a lane-based
count location. It breaks down the count data of a count location precisely by lane. The
number of observed lanes is defined via the observed lanes attribute. The lane observed
on the far right is defined via the Lane position attribute. If a detector is allocated to a count
location and therefore, to a link, the observed lanes have to be compatible with the number
of link lanes. This means that no lane which is not defined on the link may be observed.
With a lane number of two the detectors for lanes 1 and 2 are allowed to be defined. It is
however permitted, that a lane is observed by several or no detectors.

Count locations and their detectors are used less to maintain data, but more to visualize and
process thematic maps. Even though you can save count data to user-defined attributes of
count locations, you can also save them directly to user-defined attributes of the link (see
"User-defined attributes" on page 101). The advantage of saving count data directly at links is
that, in evaluations, you can compare them directly with the calculated volumes, which are also
saved with the link attributes. This approach is particularly recommended if you want to use the
matrix correction technique TFlowFuzzy (see "Updating demand matrix with TFlowFuzzy" on
page 195).
Count locations are thus primarily used for marking the position of a count in the network. You
can use the number to refer to external data, where applicable. The illustration 34 shows a
map, which is illustrated in the local position of the count location in the network, together with
the date of the last traffic count.

74

PTV AG

Chapter 2.1: Network objects

Illustration 34: Visualization of the local position of count locations with the date of the count

Notes: Do not just use count locations to integrate count values into the network. Instead use
user-defined attributes on links. However, if the current project requires the visualization of
counts or count location-related values shall be managed externally, the effort for the
coverage of count locations and detectors can pay off.
Compared to assignments for example, count locations and detectors do not have an
influence on procedures. The only exception are detectors near nodes which can be taken
into account for traffic-responsive signal control. Information provided by these detectors are
also used for ANM export to Vissim.

2.1.18

Toll systems
Toll systems are network objects which can be used to integrate toll zones and tolls into the
network model (see User Manual, Chpt. 2.38, page 561). They represent the basis for the
calculation of road tolls in the Tribut procedure (see "Basics of the assignment with toll
consideration" on page 378).

PTV AG

75

Chapter 2: Network model

In Visum, there are two kinds of toll model types:

Area toll
In case of an area toll, a geographically contiguous part of the network is designated as a
toll zone and a distance-independent charge applies if a portion of the route is located
within the toll zone. In Visum, you can define such toll zones by inserting a polygon and
specifying a toll for all associated chargeable links.
The "Congestion Charge" in London is an example of an area toll. In the city center, a toll
is charged as soon as the specified area is entered.

Matrix toll
This type of toll model is the typical road pricing scheme for motorway corridors. A subset
of links is designated as a toll zone with a small number of connections (entries and exits)
to the rest of the network. Toll prices are not defined as a total of link toll prices, but there
is an individual price for each pair (entry exit). Because of these pairs, this type of road
pricing scheme is called a matrix toll. Toll typically increases with distance but in a
degressive way, i.e. the toll per km decreases with distance.

Illustration 35: The Congestion Charge in London is an area toll

2.1.19

GIS objects
GIS objects are POI-like network objects (n categories with m objects of the type point, polyline
or polygon) that are only available during a Personal Geodatabase (PGD) connection (see
"Connection to the Personal Geodatabase and GIS objects" on page 671). This is how GIS
data can constantly be synchronized between the PGD and Visum.

76

PTV AG

Chapter 2.1: Network objects

2.1.20

Screenlines
A screenline is a polygon, which can be inserted into the network by the user with any number
of intermediate points. The screenline is inserted so that it intersects multiple links. The values
of any attributes of all links, which are intersected by the screenline, can then be aggregated
with the screenline. The following aggregate functions are thus available respectively for all or
only for the active links (see "Indirect attributes" on page 95).

Number of links which intersect the screenline.


Minimum of the values of the selected attribute from all links intersected by the screenline.
Maximum of the values of the selected attribute from all links intersected by the screenline.
Sum of the values of the selected attribute from all links intersected by the screenline.
Mean of the values of the selected attribute from all links intersected by the screenline.
Interlinking of the values of the selected attribute from all links intersected by the
screenline.

The orientation of a screenline depends on the sequence of the polygon points along its
course. It is always oriented to the right in the direction of creating. By default, arrow heads
along the course indicate the orientation. For the aggregation, you can take into account all
links in screenline orientation, all links against the screenline orientation, or all links,
independently of the direction.
In the following example, the screenline intersects two links whose volume amounts to 1,000
and 3,000 persons. The screenline then aggregates the values of the links that it intersects. In
the example it identifies a total of 4,000 persons in screenline orientation for all links and an
average of 2,000 persons.

Illustration 36: Summation and average calculations with screenlines

PTV AG

77

Chapter 2: Network model

With the aid of screenlines, you can for example determine the traffic that enters and exits the
downtown area every day in a traffic engineering study which analyses the traffic volume of a
downtown area. In illustration 37, 149,334 vehicles in PrT and 76,370 persons in PuT are
entering the downtown area.

Illustration 37: Calculation of the urban traffic volume with screenlines

Screenlines are a useful construction to calibrate an assignment model by means of counted


link data. A screenline aggregates all links intersecting it. This is useful for the calibration of the
model as cumulative assignment volumes can be compared with cumulative link count data.
When inserting screenlines, it is often recommended to adjust them to natural phenomena. A
screenline could, for example, take the course of a river. For the calibration of the model, in
principle, at least the sums of the volumes on all bridges should then agree throughout the day,
even if the distribution of the volumes to the individual bridges (route split) can differ. With the
aid of the assignment analysis, you can evaluate aggregated count data and assigned volumes
of the screenline statistically (see User Manual, Chpt. 4.4.2, page 964). With this analysis
functionality, the efficiency of the calibration can be increased considerably.

2.1.21

Junction modeling
Visum provides the possibility to model junctions in detail. There are two major fields of
application, namely the use of a detailed node impedance model among others in assignment
procedures, and the export for a micro-simulation in Vissim.

78

PTV AG

Chapter 2.1: Network objects

Element

Description

Geometry

Geometries are used to describe the geometry of nodes and main nodes in
detail. The principal elements of geometries are legs.

Leg

A leg geometry consists of a set of legs. A leg describes an entry to the node
section and the corresponding exit. A set of legs at a node or main node is
defined by the set of link orientations.

Lanes

A leg consists of a set of incoming and outgoing lanes. Through lanes are the
ones that lead right up to the adjacent node and pocket lanes start and end at
a certain distance from the node area.

Lane turn

Lane turns define a relation between an incoming lane and an outgoing lane.
They are used for detailed transport system and lane-based descriptions of the
turn conditions at a node.

Signal control

A signal control describes the total of all signal control data at one or more
nodes or main nodes. There are stage based and signal group based signal
controls, as well as external signal controls of the type RBC.

Stage

A stage is the basic unit of a signal plan in case of stage-based signal controls.
A set of signal groups is allocated to each stage. Then the green times of the
signal group result from the green times of the stages.

Signal group

A signal control contains a set of signal groups, even if it is stage-based. Signal


groups serve to describe lane turn-based signal controls in detail.

Crosswalk

Crosswalks serve to describe the pedestrian conditions at nodes and main


nodes. They refer to legs. A leg can have several crosswalks depending on
whether a center island or a channelized island has been defined.

Detector

A detector is allocated to a node or a main node. This type of detector serves


for modeling signal control, for example, traffic-responsive signal control.

Table 14: Network objects of the junction model

2.1.21.1 Link orientations


Link orientations play an essential role when defining node geometries (see "Geometries" on
page 80). The link orientations are used to determine the amount of legs. Each link has at least
four orientation attributes: From and To node orientation, and From and To main node
orientation. The two latter attributes are only defined for cordon links of a main node (see
"Main nodes and main turns" on page 48). The orientations are always undefined for closed
links. A link is closed, if its transport system set is empty or if the number of lanes is zero. If a
link is not closed, it is an open link.
Up to sixteen link orientations can be defined at a node or main node. If a node or main node
has more than sixteen open incoming links or more than sixteen open outgoing links, all link
orientations will be undefined. At such nodes, a geometry and thus a signal control cannot be
defined.
The allocation of link orientations complies with specific rules. If an incoming link and its
opposite outgoing link are open, the To (Main) Node Orientation of the incoming link and the
From (Main) Node Orientation of the outgoing link are identical. If there is an incoming link
whose opposite direction is closed, you can allocate the same orientation to an outgoing link,
as long as its opposite incoming link is also closed. You can also combine incoming one-way

PTV AG

79

Chapter 2: Network model

roads and outgoing one-way roads in one leg (see "Geometries" on page 80), if you give them
the same orientation.
Whether Visum calculates the link orientations automatically at a node or main node or not,
depends on the attribute Use automatic link orientation. If the link orientations are calculated
automatically, the type of calculation depends on the option set under Network > Network
parameters > Network objects > Link orientations (see User Manual, Chpt. 2.14.4,
page 280). Normally, the value is set to 8. This means that Visum picks the best orientations
from the four main directions (N, E, S, W) and the four secondary orientations (NE, SE, SW,
NW). The entry angle of the link at the node or main node is decisive when selecting the
orientation. If the orientations do not suffice i.e. the node or main node has more than eight
legs Visum adds the subordinated secondary orientations (e.g. NNE).
Notes: In Visum versions prior to 11.5, this setting did not exist for the calculation. Visum used
to implicitly calculate with today's setting 4. This means that Visum first tried to allocate only
the main orientations, and only switched to the secondary orientations in case of nodes with
more than four legs. The subordinated secondary orientations were not used in earlier Visum
versions.
Please note that you can define varying numbers of legs at a node or main node, depending
on the number of pairs of incoming and outgoing one-way roads that are given the same
orientation.

2.1.21.2 Geometries
In macroscopic traffic models, an at-grade junction is represented by a node (point object) with
turns. Macroscopic modeling, however, does not reveal anything on the detailed geometry or
the geometric design of a junction. Nearly the same applies to the node control. The optional
extension of the Visum network model by node geometry and junction control can be used in
the following fields:

Calculating the performance at a node


Considering node impedances during assignment
Providing entire junctions for the microscopic model Vissim

A node geometry consists of the items node legs, lanes, lane turns, detectors, and crosswalks.
If a signal control is allocated to a node, its data refer to the node geometry. By default, no
geometry data are provided at a node. These are generated not until the first access.

Legs
The principal elements of the geometry are the legs. A node/main node can have up to sixteen
legs. The set of legs is determined by the orientations of the incoming and outgoing links (see
"Network objects of the junction model" on page 79). For each used link orientation, exactly
one leg is generated. Legs can thus either consist of an incoming link and its opposite direction,
or of an incoming one-way road and an outgoing one-way road.
Legs can have a center island, a channelized island, or both. For a center island to exist, the
center island length and width both need to have a value > zero. For a channelized island to
exist, the channelized island length needs to be > zero. The Stop line position attribute is only
used for the export to Vissim. Legs also possess a set of lanes.

80

PTV AG

Chapter 2.1: Network objects

Lanes
There are incoming lanes and outgoing lanes, as well as through lanes and pockets. The
number of through lanes at a leg cannot be changed. It is based on the set number of lanes at
the links which underlie the leg. Therefore, if the incoming link of the leg has three lanes
(Number of lanes attribute on the link) and at least one transport system, the leg features
three incoming through lanes. If the number of lanes at this link is changed, the number of
through lanes at the leg will be adjusted automatically. We recommend double-checking the
adjusted geometry data after such modifications. Since at least one open link underlies each
leg, each leg features at least one through lane.
The number of lanes at a leg can be changed by creating pocket lanes (pockets). Pocket lanes
always refer to a through lane on which they originate (origin lane). In contrast to through lanes,
pockets can be removed again. For pockets, a length can be specified. This is used during
Vissim exports and for specific methods of impedance calculations at nodes.
By default, the transport system set permitted on a lane corresponds to the transport system
set of the underlying link. For pockets, the transport system set of the origin lane is used by
default.
Note: The numbering of the lanes differs from the one in Vissim.

Lane turns
A lane turn connects an incoming lane with an outgoing lane. When generating a geometry
automatically, a set of lane turns is also generated automatically. In order to define a lane turn,
the turn or main turn between the link underlying the incoming lane and the link underlying the
outgoing lane must be open. This means that it needs to have at least one transport system.
It is usually not desired that lane turns intersect. Two lane turns, for example, intersect if one
of them makes a left turn on a right lane and the other one goes straight on a left lane. This is
yet possible and desired, if the left turn is a PrT turn and the other one a PuT turn. In this way,
a tram can, for example, be modeled in central position.
The set of lane turns basically determines the results of the node impedance calculations at a
node/main node.

Crosswalks
Crosswalks are objects that connect the sides or the islands of a leg per direction. Depending
on the combination of islands at a leg, you can define up to six crosswalks. If the node leg e.g.
has a center island (i.e. its center island length and width are both > zero) and a channelized
turn, six crosswalks can be defined: One between a side and the center island, one between
the center island and the channelized island, one between the channelized island and the other
side, and one each in the opposite direction.
Crosswalks are exported to Vissim. For crosswalks, a pedestrian volume can be specified.
This is relevant when calculating the node impedance using ICA (see "Intersection Capacity
Analysis according to the Highway Capacity Manual (ICA)" on page 229).

PTV AG

81

Chapter 2: Network model

Leg templates and geometry templates


In order to ease the input, leg templates can be used for legs. With the aid of leg templates, a
set of predefined lanes, lane turns, and crosswalks are generated at a leg. Contrary to earlier
program versions, the object's reference to the template is not kept when using leg and
geometry templates. Previously, legs could not be edited, if they were allocated a template.
Now, templates are used exclusively to define leg and node geometries.
For the generation of leg templates, existing legs are used. The attribute values of the leg are
transferred to the template. They can, however, be edited later on. A leg template consists of
lane templates. If a leg template is generated from a leg, the lanes of the leg are used as a
model for the lane templates. The lane templates can also be edited later on.
Leg templates can only be used at geometries of 3 or 4 legs. The data must match so that a
leg template can be used at a leg. If a template is suitable for nodes with three legs, it can thus
not be used for legs at nodes with four legs. The number of incoming and outgoing lanes of the
leg and of the template must also be identical.
Contrary to leg templates, geometry templates can be applied to all legs of the node. They can
also be used exclusively at nodes with 3 or 4 legs. A geometry template is made up of several
leg templates. When using a geometry template, the leg templates are applied to the legs of
the node. To determine which leg template is to be used at which leg, a reference leg must be
specified for the template. Geometry templates can only be used, if at least one valid reference
leg exists, so that all leg templates can be used in the right order for all legs at the node.

2.1.21.3 Signal control


Signal controls (SCs) can be allocated to nodes and main nodes. There are four types of signal
controls: signal group based, phase based, RBCs (ring-barrier controller), and external signal
controls (Vissig). In case of signal-group SCs, signal groups can be defined immediately. In
case of stage-based SCs, stages must be defined first, and after that, signal groups can be
allocated to the stages. Vissig controls are managed with an external program (see "External
controls" on page 83).
Note: For further information please refer on RBCs, please refer to the RBC manual in the
Doc\Eng folder of your Visum installation directory.
Signal controls can be switched off. In this case, nodes and main nodes for which the signal
controls have been switched off are treated as two-way stop nodes in procedures such as ICA
and signal time optimization. So switching off a signal control will change the node control type.
Note: An SC can be allocated to multiple nodes or main nodes. However, we only
recommend to do so for Vissig controls, as the procedure Signal cycle and split
optimization only delivers good results for multiple nodes and main nodes in combination
with Vissig controls. The number of the coordination group of the SC plays a role in the
Optimization of the SC offset operation (see User Manual, Chpt. 2.40.14.1, page 633).
The key attributes of a signal group are its Green time start and its Green time end. These
attributes are relevant to the node impedance calculation (see "Signalized nodes" on
page 230). In external controls signal groups can have two pairs of green time start and green
time end. Thus, you can model a second green time, represent it correctly in the signal time
display of the network editor and take it into account in the node impedance calculation. In case

82

PTV AG

Chapter 2.1: Network objects

of stage-based SCs, green time start and green time end of a signal group correspond to the
green time start and green time end of its stage. If for a signal group or stage, the Green time
start attribute is 0 and the Green time end attribute is identical with the SC cycle time, this is
interpreted as permanent green. Both attributes are restricted by the cycle time of the SC. The
Green time end can have a smaller value than the Green time start. In this case, the green
time is calculated by subtracting the difference of both values from the SC cycle time. The
green time cannot fall below the minimum green time of a signal group.
Signal groups also have the attributes Amber and Allred. Furthermore, intergreens can be
defined between signal groups. All of these values are important when calculating the signal
cycle and split optimization. Hereby, the Used intergreen method attribute of the signal
control determines whether the amber and all-red time or the intergreen matrix is used for
optimization. The ICA loss time adjustment attribute is used in the calculation of the
impedances with ICA to determine the effective green times with the aid of the specified green
times. The Minimum green time attribute is used for signal cycle and split optimization,
serving as a low threshold value for the green time calculated. The Vissim coordinated
attribute is only relevant for the Vissim export.
The relation between the signal control and the network is established when allocating the
signal groups to lane turns. Each signal group can be allocated to any number of lane turns.
Prerequisite is, that the lane turns are located at nodes or main nodes which are allocated to
the SC of the signal group. Likewise, any number of signal groups of the SC can be allocated
to each lane turn that is allocated to the node or main node of the lane turn. A signal group can
also be allocated to any number of crosswalks. A crosswalk, however, can only refer to one
signal group. The data model is not restricted here. As an example, Visum does not check
whether a signal group is allocated to each lane turn. It does not check either whether
conflicting volumes have overlapping green times. Should the signal control be used to
determine node impedances, it is recommended to carry out the respective ICA network check
option to detect incomplete junction models (see User Manual, Chpt. 2.41, page 640).
Note: It is recommended to complete the modeling of a node or main node, before allocating
signal groups to lane turns. When deleting or inserting lane turns, the signal control data can
get lost.

External controls
A special feature of external SCs is that the data are not saved in the version file. Vissig control
files are saved in the *.sig format. This way, they can also be accessed by other programs, for
example Vissim. To edit external control data in Visum, you use the Vissig program. In external
controls, multiple signal programs can be stored. This is not the case for signal group based or
stage based controls. Therefore, the SC attribute Signal program number is only relevant
when dealing with external controls. Visum accesses the data saved in the control file at certain
times. This is, for example, the case when opening a version file or when running the
operations Signal cycle and split optimization and Update impedances at node via ICA.
Note: Up to Visum 12, RBCs belonged to the external controls. Now RBC files in the *.rbc
format are still read in, but are no longer used.

PTV AG

83

Chapter 2: Network model

Stage templates
Stage templates can be used to easily generate signal control data at a node or main node
(see User Manual, Chpt. 2.40.13.3, page 629). If a stage template is allocated to a node, the
SC of the node then possesses a lot of stages and signal groups. Lane turns are already
allocated to the signal groups. This means, for example, that conflicting volumes are signalized
with different green times.
Note: Prerequisite for the use of a stage template is, however, that a stage-based SC is
already allocated to the node or main node.

2.1.22

Network check
Visum supports the user when checking the consistence of the network model. If the network,
for example, contains zones which are not connected to the rest of the network, this indicates
a modeling error. To identify such errors, several tests are provided (see User Manual, Chpt.
2.41, page 640).

2.2

Spatial and temporal correlations in Visum


In Visum, the following can be specified:

2.2.1

Calendar
Valid days
Time series
Analysis time slots

Calendar and valid days


You can specify a calendar and valid days for your network.

2.2.1.1

Calendar

With the aid of the calendar, the modeling of transport supply (in PuT and for the DUE
procedure in PrT) and demand (for the dynamic procedures of PrT and the headway-based
and timetable-based assignments of PuT) can be refined considerably. It is not only possible
to model any day, but also to manage any combination of weekdays or individual days. The
calendar is global, i.e. only one of the following three calendar options can be applied to the
entire model. Use of the calendar is optional. The following options can be selected for a
network model:

84

No calendar
The transport options for one day are indicated. The analysis period is thus automatically
one day and cannot be edited by the user.

PTV AG

Chapter 2.2: Spatial and temporal correlations in Visum

Weekly calendar
The demand (for the dynamic procedures of the PrT and for the headway-based and
timetable-based procedures of the PuT) and the PuT supply can be differentiated for the
individual weekdays Monday to Sunday. It is possible to specify for each vehicle journey
section weekdays on which there will be a service. The analysis period can be any time
period of entire days within the week (such as Monday to Friday).
Annual calendar
Valid days can be defined for any day of the year. The analysis period can be set to any
time period (in entire days) within the calendar period (e.g. 14th July 2008 to 20th July
2008).

The calendar takes effect in the following procedures (all other procedures are not affected):

Dynamic assignment in PrT


In the Dynamic stochastic assignment and DUE, traffic supply can be time-varying. Timevarying attributes are used (see "Time-varying attributes" on page 105). When using a
calendar, valid days can be specified for these time-varying attributes, on which they
should take effect.
Assignments in PuT
Valid days are allocated to and affect single vehicle journey sections.
PuT analysis (operation PuT operational indicators)
PuT passenger survey

2.2.1.2

Valid days

Valid days are closely linked to the calendar as they can be specified on the basis of the
selected calendar. First the kind of calendar is thus chosen when modeling, and then valid
days are specified on the basis of the respective calendar.
Valid day is a freely definable set of days of the calendar used. If a weekly calendar is used, a
valid day may comprise the days Monday to Friday, for example (the valid day then is
designated Mondays to Fridays).
In PuT the timetable is based on a calendar (see "Calendar" on page 84). A valid day can be
assigned to each vehicle journey section. Optionally, this can consist of an individual day or an
example week, however, a defined period on the calendar can also be used. In each case, the
availability of individual vehicle journey sections can be specified by valid days. A valid day is
a freely definable set of days of the underlying calendar. For each valid day a separate name
can be allocated. Valid days usually represent regularly recurring patterns, such as Monday to
Friday, but these could also be individual days (for example 01.01.2009). How to define a valid
day depends of the selected calendar:

PTV AG

No calendar
Exclusively uses the valid day daily. It is not possible to create further valid days. Demand
and supply are modeled for an unspecified, recurring day in this case.
Weekly calendar
Apart from the predefined valid day daily any desired valid days can be created, which are
specified by entering one or several valid weekdays (e.g. all weekdays with the valid day
name Mon-Fri).

85

Chapter 2: Network model

Annual calendar
Valid days can be defined for any day of the year within the calendar period. The following
possibilities are provided:
fixed time period (e.g. 01.01.2008 to 30.06.2008)
weekdays (e.g. Mon-Fri)
hard rule (for example during the summer holidays)
free selection of calendar days (for example 24.12.2007 and 31.12.2007)

Valid days play a minor part in PrT. Valid days can be used in the following assignment
procedures:

Dynamic stochastic assignment (see "Dynamic stochastic assignment" on page 419)


Dynamic User Equilibrium (DUE) (see "Dynamic User Equilibrium (DUE)" on page 389)

Tip: In these procedures, the transport supply can be time-varying. Time-varying attributes
are used (see "Time-varying attributes" on page 105). When using a calendar, valid days can
be specified for these time-varying attributes, on which they should have an effect.

2.2.2

Time reference of the demand (time series)


Just like the transport supply and the assignment, any demand has a time reference.
In statistic PrT assignments, the demand always refers to the analysis period. The demand
time series allocated to the demand segment and the start time are irrelevant here.
This is different in the dynamic PrT assignments (DUE and Dynamic Stochastic assignment)
and the headway-based and timetable-based assignment in PuT. Demand matrices do not
have an explicit time reference here, but are described by a start time and a time series.
Note: A time series must be allocated to the demand segments in order to calculate an
assignment with these procedures.
The start time specifies the time and if the weekly or annual calendar is used - the day on
which the period referred to by the demand in the matrix starts. The end of the period is
calculated from the length of the assigned time series.
In Visum, there are two different ways to define so-called standard time series:

86

For time series as percentages a weight is specified for each time interval. It specifies
which share of the total demand accounts for the respective time interval. If a time series
as percentages is used for a demand segment, a demand matrix must also be specified,
whose demand is distributed temporarily with the specified weights. This matrix must
contain the number of travel demands in the time period, defined by the starting time and
the length of the time series.

PTV AG

Chapter 2.2: Spatial and temporal correlations in Visum

Illustration 38: Time series by percentage

However, for time series of matrix numbers for each time interval a separate demand matrix
is specified. It contains the travel demands of this time interval only.

Illustration 39: Time series of matrix numbers

Note: When using time series of matrix numbers, it is possible to specify a value for the
demand for each OD relation and time interval. This way, asymmetric changes of the demand
(load direction) can be illustrated. For time series as percentages however, the same factor
applies to each OD relation per time interval.
Time series of matrix numbers require a full matrix for each time interval, which must be
generated and also saved. In order to save the effort and still be able to model a certain load
direction in the demand, Visum provides demand time series as a compromise. These are
generated on the basis of a standard time series, whereas a different standard time series can
be specified for each pair of zone types. In this way, it is possible to specify deviating time
series for selected pairs of origin and destination zones with known structural features (for
example purely residential or commercial areas).
For each demand segment, either a fixed demand matrix together with a time series as
percentages is specified, or a demand time series which itself is a time series of matrices.
Moreover, a start day and the start time per demand segment must be specified.

PTV AG

87

Chapter 2: Network model

Note: The start time shifts the time intervals of the time series since it is specified relative to
this start time point. If the time series defines an interval A from 0 am to 1 am and an interval
B from 1 am to 2 am, and the start time is set to day 2 at 2 pm, the share of the demand
defined in interval A will arise on day 2 from 2 pm to 3pm, and the share of interval B on day
2 from 3 pm to 4 pm. Outside of these times, for example on the first day of the calendar,
there is no demand.

2.2.3

Time reference of the volumes: Analysis time slots and projection


Volumes always have at least an implicit time reference which they get from the time reference
of the demand (if the demand matrix contains the demand of the peak traffic hour for example,
the assignment results will also refer to the peak hour). To apply the resulting volumes to a
shared time unit and then project them evenly to longer temporal horizons, the following
analysis time slots are provided in Visum.

88

The calendar period calendar period covers the set calendar, i.e. one, seven or any
number of days.
The Time reference of the demand determines the number of travel demands within the
assignment time interval. The time reference is established by the start time of the demand
segment and the time series allocated to the demand segment (see User Manual, Chpt.
3.1, page 731).
The assignment time interval mainly serves to determine the share of the demand that
needs to be assigned. It is crucial that the assignment time interval of each assignment lies
within the analysis time period. In the assignment, the share of the demand that accounts
for the assignment time interval according to the time series is assigned to the paths found
in this time period. The assignment area and the demand time series need to overlap, since
otherwise no demand exists within this time period and no assignment can be calculated.
An assignment time interval can only be specified for dynamic assignments (DUE, Dynamic
Stochastic assignment) of the PrT and for the headway-based and timetable-based
assignment of the PuT. The assignment time interval is specified in the parameters of the
assignment procedure. In all statistic PrT assignments (Equilibrium assignment,
Incremental procedure, Equilibrium_Lohse, Stochastic assignment, Tribut), the assignment
time interval automatically corresponds to the analysis period.
The analysis period (AP) represents the period on which all evaluations are based. If no
calendar is used, the analysis period is one day. If a weekly or annual calendar is used, the
analysis period is specified in the procedure parameters. The analysis period is a time
period between at least one day and a maximum of the whole calendar period Initially,
calculated results are available for the analysis period, before they are converted into
analysis time intervals or the analysis horizon. The analysis period must be within the
calendar period. The assignment intervals must lie completely within the analysis period.
For the analysis period projection factors can be specified at the demand segments, which
project the assignment results from the assignment time interval to the analysis period.
They serve to scale the demand to the analysis period. If the time period of the demand
matrix is identical to the analysis period, the projection factor is 1. If the demand matrix is
based on one day, yet the analysis period on a week, the factor would have to be set to 7
(when assuming that the traffic is the same on all 7 days of the week).

PTV AG

Chapter 2.2: Spatial and temporal correlations in Visum

The analysis horizon (AH) is a longer time period on which the results can be projected.
It is not specified explicitly. Instead, the projection factors on the analysis horizon are
predefined. These can be specified at the demand segment (for the volumes) and at the
valid day (for the operator model) (see "Basic calculation principles for indicators" on
page 641). As a rule, an analysis horizon of a year is regarded. Since a different projection
factor can be specified for each demand segment, the projection factor of daily values to a
year can for example be smaller for a demand segment Pupils than for a demand segment
Commuters, as the pupils have more vacation days on which they do not generate any
traffic. The volume of a network object in terms of the analysis period is the total of the
volumes of all paths traversing the network object, multiplied by the projection factor of the
demand segment. This projection factor compensates that the assignment time interval
may cover only a part of the analysis period.
Analysis time interval (AI)
For a more refined temporal evaluation of calculated results, analysis time intervals can be
defined (see "Temporal distinction with analysis time intervals" on page 92). Each analysis
time interval needs to lie completely within a calendar day of the analysis period.

Note: Contrary to the analysis period, which incorporates the assignment time interval and
thus requires a projection of the volumes, the analysis time intervals identify the exact volume
which arises in the respective time period. Thus, the projection factors of the individual
demand segments do not have an effect on the volume per analysis time interval. If the
analysis period is completely covered by analysis time intervals, the relationship between the
total volumes for the intervals and the volume related to the analysis period exactly
corresponds to the projection factor.
DSeg 1
DSeg i
Demand segments

Calendar period CP
Day n

Day 1
Analysis period AP in CP
AP

Analysis time interval AI in AP

AI

Assignment time interval ATI in AP

ATI

Demand starts at start time of DSeg + from_time of standard time series

Illustration 40: The relationship between the different analysis time slots

PTV AG

89

Chapter 2: Network model

Example of projection factors


Volumes are to be determined per week in a model with a weekly calendar. To reduce the run
time of an assignment procedure, the entire week should not be used as an assignment time
interval. It is assumed that the demand and the supply of week days Monday to Friday are the
same. Demand data are available for the standard working day, Saturday and Sunday.
This is solved in the following way. Three demand segments are set, which each represent the
demand on the working day, Saturday and Sunday. Each demand segment is provided with an
appropriate time series, whereas the standard working day has to be one of the days Monday
to Friday. Three assignments are calculated. The assignment time interval is only one day,
namely Tuesday (representing the standard working day), Saturday and Sunday.
A week is set for the analysis period and a year for the analysis horizon. The following
projection factors are used, to correctly project the volumes.
Demand segment

Projection factor AP

Projection factor AH

Standard working day

365
---------- 5 = 260
7

Saturday

52

Sunday

52

Table 15: Deriving projection factors for AP and AH

Example of the interaction of analysis time intervals and time series


To calculate an assignment, the assignment time interval and the time, which is valid for the
demand, have to overlap. Three examples are shown below. In the first case (illustration 41),
the demand and assignment intervals do not match and the assignment cannot be calculated.
Visum then issues the error message No OD pair shows demand > 0 within assignment
time interval. No connections calculated. In the second (illustration 42) and third example
(illustration 43) assignment time interval and validity period of the demand overlap so that an
assignment can be calculated. The table 16 provides an overview on analysis time intervals
and time series of the three examples.
Calendar Assignment Analysis
time interval period

DSeg
DSeg
start day start
time

Standard
Standard
Assignment
time series time series can be
from
to
calculated

Ex. 1 Weekly
calendar

Mon 06:3007:30 a.m.

Mon-Mon Mon

01:00:00 00:00:00
a.m.

02:00:00

No

Ex. 2 Weekly
calendar

Mon 06:3007:30 a.m.

Mon-Mon Mon

05:30:00 00:00:00

02:00:00

Yes

Ex. 3 Weekly
calendar

Mon 06:3007:30 a.m.

Mon-Mon Mon

00:00:00 05:30:00

07:30:00
a.m.

Yes

Table 16: Example of the interaction of analysis time intervals and time series

90

PTV AG

Chapter 2.2: Spatial and temporal correlations in Visum

Time series of the


demand segment

Mo

Tu

Calendar period CP
1:00

3:00
6:30

Analysis period AP in CP

7:30

AP

Assignment interval AI in AP

AI

Illustration 41: Assignment not possible because the validity of the demand and the assignment time
interval do not overlap.
Share of the demand
that is assigned

Time series of the


demand segment

Mo

Tu

Calendar period CP
5:30

Analysis period AP in CP

Assignment interval AI in AP

6:30

7:30

AP

AI

Illustration 42: The demand between 6:30 and 7:30 a.m. is assigned.

PTV AG

91

Chapter 2: Network model

Share of the demand


that is assigned
DSeg
Start time
Mo. 00:00

Time series of the


demand segment

Mo

Tu

Calendar period CP
5:30

Analysis period AP in CP

Assignment interval AI in AP

6:30

7:30

AP

AI

Illustration 43: The demand between 6:30 and 7:30 a.m. is assigned.

2.2.4

Temporal and spatial differentiation of calculation results


The results of the impact models, after the completion of the calculation, are available as a
large number of attributes, some of which refer to the routes or connections found in the
assignment procedures, while the majority refers to the network objects (links, nodes, turns)
and all objects of the PuT network model (see "Impact models" on page 205). In addition to
structuring the content, many attributes can additionally be differentiated by space, by
modeling territories (territorial section) or by time, by creating analysis time slots (time section).
An extremely high level of model detail can be achieved with a combination of temporal and
spatial distinctions. Passenger kilometers, costs, and revenue, for example, can be displayed
for vehicle journeys run by a specific line using low-floor buses between 6:00 and 7:00 a.m. in
the community territory.

2.2.4.1

Temporal distinction with analysis time intervals

If a period which is shorter than the analysis period shall be analyzed for the temporal
differentiation of calculation results, several analysis time intervals can be specified (see User
Manual, Chpt. 4.2.2, page 949). The analysis time intervals must lie within the analysis period.
They have to neither be consecutive nor of the same length. The analysis time period, must
however, be within a day, is therefore not allowed to contain a day changeover. Provided that
attributes can be assigned on a time basis, the portion assigned to each defined analysis time
interval can be identified separately.
In addition, you can show aggregated data across multiple analysis time intervals. To do so,
you can create additional analysis time intervals, assign them existing time intervals, and
specify an aggregation function. Using these time intervals, you can output data for more than
a day.

92

PTV AG

Chapter 2.2: Spatial and temporal correlations in Visum

In PrT, evaluations broken down by time slices can only be made for the dynamic assignment
DUE and the dynamic stochastic assignment (see "Dynamic User Equilibrium (DUE)" on
page 389 and "Dynamic stochastic assignment" on page 419). The reason is that only in those
assignments, the traffic demand can be time-varying. Therefore, evaluations for analysis time
intervals within the analysis period can only be made in the course of these procedures. The
link volume of the rush-hour traffic from 7 to 9 am can thus for example be evaluated
separately.
In PuT, evaluations broken down to time slices are only possible for the timetable-based
assignment procedure. In the timetable-based assignment procedure however, there are no
connections that are fixed in time, so that it is not possible to apply assignment results to a
specific analysis time interval.

2.2.4.2

Spatial distinction with territories

For spatial distinctions, the user initially defines territories (see "Territories" on page 52). These
are network objects, which are only relevant for analysis purposes and possess a polygon
(boundary) as the most important feature. Provided that attributes such as the passenger
kilometers of a line can be spatially localized, the share assigned to each territory can be
identified separately. Thus all passenger kilometers will be calculated, which arise within the
territory polygon. To calculate such an evaluation, the Territory indicators procedure must be
run (see User Manual, Chpt. 4.4.3, page 970). The results can be displayed in the list
Territories > Basis (see User Manual, Chpt. 12.1.10, page 1386) and are also available in the
filters and in the graphic parameters in the form of territory attributes.
In PuT even more detailed evaluations can be carried out (see "Operator model PuT" on
page 521). Here you can even calculate indicators for combinations of territories, objects of the
line hierarchy (transport system, main line, line, line route, time profile, vehicle journey) and as
an option, vehicle combinations. You can thus for example calculate the number of service
kilometers traveled by the vehicle combination tram on line 2 in the urban area. Here, an
additional distinction can be made for most of the indicators on a temporal basis. You would
thus get just the service kilometers between 5 and 6 pm for example. Use the procedure PuT
Operating Indicators to carry out such an evaluation (see User Manual, Chpt. 7.3.1,
page 1219). The results can be displayed in the Territories > PuT detail list (see User
Manual, Chpt. 12.1.10, page 1386).

2.2.5

Adjustment of the capacities to the demand values


Please note that the link and turn capacities can have different units depending on the selected
assignment procedure. While in statistic assignments of the PrT (such as the Equilibrium
assignment) the link capacity is, for example, entered in car units per analysis period (PCU/
AP), in the dynamic DUE procedure, the link capacity is interpreted in car units per hour (PCU/
h). Although the Capacity attribute is attributed identically at the link, its unit is interpreted
differently depending on the assignment procedure that is used.
Furthermore, the units in which link and turn capacities are modeled always need to match the
units of the demand matrix. It is thus not allowed to manage link capacity values in unit PCU/h
and assign a demand matrix in the same model which contains values for the whole day.

PTV AG

93

Chapter 2: Network model

More detailed information on which units are used for capacity and demand in the individual
procedures will be given in the section on input and output attributes of each assignment
procedure (see "User model PrT" on page 211).

2.3

Attributes
In Visum, network objects have many attributes you can save your input or output data to.
Generally, there are two types of attributes:

Direct attributes
Indirect attributes

Direct attributes contain data that refer directly to a network object, e.g. the length or volume of
a link (see "Direct attributes" on page 94).
Indirect attributes refer to the relations between one network object and other network objects.
E.g. the sum of volumes of all outgoing links is an indirect attribute of a node (see "Indirect
attributes" on page 95).
The number of attributes available in Visum is not static, but can be extended by user-defined
attributes (see "User-defined attributes" on page 101).
Time-varying attributes play a special role in dynamic assignments (see "Time-varying
attributes" on page 105).

2.3.1

Direct attributes
Each network object is described by means of Visum attributes (direct attributes). The following
types are differentiated as follows:

Input attributes (e.g. stop number) and


calculated attributes, which are also called output attributes (for example, the number of
Passengers boarding at a stop)

Each Visum attribute is described as follows:

by a name (for example Number)


by a code (for example No.)
by an attribute identifier (attribute ID), which is always in English (for example No)

Note: The Attribute.xls file in the Doc folder of your Visum installation contains a complete list
of all types of Visum network objects (which in connection with databases are also called
tables) and of all attributes of each network object. There, you find the ID of each attribute, by
which it can be identified clearly, its name and code as well as the description of what each
attribute indicates.
The table 17 shows an example of some input and output attributes of the link.

94

PTV AG

Chapter 2.3: Attributes

Attribute

Input attribute

Calculated attribute

Number

TSysSet

Capacity PrT

Number of lanes

t0-PrTSys

tCur-PrTSys

Capacity PrT [Veh]

Saturation PuT seats

Passenger kilometers

Table 17: Examples of input and output attributes at the link

Apart from predefined Visum attributes, for each network object type, user-defined attributes
(see "User-defined attributes" on page 101) can be created and edited. They are also direct
attributes of the respective network object type and can be edited, saved, displayed graphically
and in tables like Visum attributes.
In addition, for some network object types, it is possible to overwrite defined attribute values
with other values for a limited time (see "Time-varying attributes" on page 105).

2.3.2

Indirect attributes
Besides the direct attributes of the currently selected network object, you can also access its
indirect attributes. These are direct objects of other network object types that are network
model-related to the selected object. Therefore, for a network object, both the direct attributes
as well as its relations to other network objects can be selected.
Indirect attributes give access to properties of other network objects, which bear a logical
relation to the base object. It is often convenient to filter network objects not only by their own
properties, but also by the properties of their logical neighbors in the network, or to display
these properties next to their own properties in listings or graphics (for example displaying the
aggregated values of the attributes of all stop points, which belong to a stop, in a list).
Relations between network object types are displayed explicitly in the user interface and allow
access to all attributes of the referenced network object types (e.g. Link From node
Outgoing Links). The three existing kinds of relations between the currently selected network
object type and other network object types are indicated as follows.

PTV AG

exactly one relation (1...1). Such a relation, for example, exists between connector and
zone: each connector connects exactly one zone with the connector node. In the example
of table 18, for connectors, the indirect attribute Zone\Number of connectors is output.
For each connector, you can thus see how many other connectors the zone of this
connector has.

95

Chapter 2: Network model

Selection of the indirect attribute Zone\Number of


connectors in the attribute selection window

The indirect attribute is displayed in the list next to


the direct attributes of the connector.

Table 18: Example of a 1..1 relation in the Visum network model

either one or no relation (0..1). Such a relation, for example, exists between nodes and
main nodes. A node can be allocated to a main node, but does not have to be. Besides,
each node can be allocated to just one main node. As depicted in table 19, with the aid of
indirect attributes you can see for each node to which main node it is allocated by selecting
the name of the main node as indirect attribute (Main node\Name).

Selection of the indirect attribute Main node\Name The indirect attribute is displayed in the list next to
in the attribute selection window
the direct attributes of the node.
Table 19: Example of a 0..1 relation in the Visum network model

several relations (0..n). Such a relation, for example, exists between stop areas and
stop points. Since no 1:1 link exists between the network objects types in this case, you
need to select an aggregate function which pools all related network objects (the aggregate
function Sum for example ensures that all indirect attributes are allocated with the sum of,
for example, all boarding passengers at all stop points that have a relation to the selected
stop area). Below, an example is given for each of the aggregate functions provided in
Visum.

If a 0..n relation has been selected at the Visum interface, the aggregate functions of either all
network objects or merely the active ones are displayed. Aggregate functions are not provided
in case of 1..1 and 0..1 relations, as there is only one relation from the current network object
to another network object in this case (just one link type is for example allocated to each link).
For 0..n relations, the following aggregate functions are provided:

96

PTV AG

Chapter 2.3: Attributes

Count and CountActive


Determine the number of associated network objects. In table 20, the number of stop areas
associated with a stop is determined.

Selection of the indirect attribute Count:Stop


areas in the attribute selection window for stops

The indirect attribute is displayed in the list next to


the direct attributes of the stop.

Table 20: Example of a 0..n relation with aggregate function Count

Min and MinActive


Determine the minimum value of all associated network objects for the selected attribute.
In table 21, the minimum number of boarding passengers at all stop points of the stop area
is output.

Selection of the indirect attribute Min:Stop


points\Passengers boarding(AP) in the attribute
selection window

The indirect attribute is displayed in the list next to


the direct attributes of the stop area.

Table 21: Example of a 0..n relation with aggregate function Min

PTV AG

97

Chapter 2: Network model

Max and MaxActive


Determine the maximum value of all associated network objects for the selected attribute.
The table 22 displays the maximum number of boarding passengers at all stop points of the
stop area.

Selection of the indirect attribute Max:Stop


points\Passengers boarding(AP) in the attribute
selection window

The indirect attribute is displayed in the list next to


the direct attributes of the stop area.

Table 22: Example of a 0..n relation with aggregate function Max

Sum and SumActive


Determine the total of the values of all associated network objects for the selected attribute.
The table 23 displays the total of boarding passengers at all stop points of the stop area.

Selection of the indirect attribute Sum:Stop


points\Passengers boarding(AP) in the attribute
selection window

The indirect attribute is displayed in the list next to


the direct attributes of the stop area.

Table 23: Example of a 0..n relation with aggregate function Sum

98

PTV AG

Chapter 2.3: Attributes

Avg and AvgActive


Determine the mean of the values of all associated network objects for the selected
attribute. The table 24 displays the average number of boarding passengers at all stop
points of the stop area.

Selection of the indirect attribute Avg:Stop


points\Passengers boarding(AP) in the
attribute selection window

The indirect attribute is displayed in the list next to the


direct attributes of the stop area.

Table 24: Example of a 0..n relation with aggregate function Avg

PTV AG

Concatenate and ConcatenateActive


String all values of the associated network objects together for the selected attribute. The
table 25 displays the number of boarding passengers at each stop point of the stop area.
At the stop points of stop area 2012 for example, 545 and 1046 passengers board each.

99

Chapter 2: Network model

Selection of the indirect attribute


Concatenate:Stop points\Passengers
boarding(AP) in the attribute selection window

The indirect attribute is displayed in the list next to the


direct attributes of the stop area.

Table 25: Example of a 0..n relation with aggregate function Concatenate

100

Histogramand HistogramActive
Contrary to the aggregate function Concatenate, each occurring value is issued only once
along with the frequency of its occurrence. This display offers more clarity especially if the
user wants to see which values occur at all and how many times. The table 26 illustrates
the difference between the Concatenate and the Histogram display. Here, for each line, the
number of stop points of the associated line routes is displayed. For example, 13 line routes
are allocated to line S4. Two of the line routes have 10 stop points, 4 line routes have 20
stop points, and 7 line routes have 21 stop points.

PTV AG

Chapter 2.3: Attributes

Selection of the indirect attribute


The indirect attribute is displayed in the list next to the
Histogram:Line routes\Number stop points direct attributes of the line.
in the attribute selection window
Table 26: Example of a 0..n relation with aggregate function Histogram

Indirect attributes can also be used as source attributes for operation Intersect and thus allow
the combination of logical and geometric relations (see "Intersect" on page 677).

2.3.3

User-defined attributes
For all network objects - just as in databases or other geographical information systems - you
can define your own attributes in addition to the default input and output attributes in Visum.
User-defined attributes can be edited and stored just like predefined Visum attributes.
The following data can thus be included in the model.

PTV AG

Structural data of traffic zones (such as the number of households or the number of
workplaces), which serve as input data for demand modeling.

101

Chapter 2: Network model

Illustration 44: Structural data of zones stored in user-defined attributes

102

Count data of links over several years (e.g. DTV2005, DTV2006)

PTV AG

Chapter 2.3: Attributes

Illustration 45: Count data stored in user-defined link attributes

Different categories of vehicle journeys


User-defined attributes for storing calculation results from Multi-Edit operations (see User
Manual, Chpt. 2.3, page 169). The table 27 shows an example in which the line costs per
kilometer of the link length are calculated with the aid of a formula and the result is saved
in the user-defined attribute Cost_per_Km.

Line name

Costs [CU]

Line network length [km] Cost_per_Km [CU/km]

001

13,012.86

22.94

567.06

002

22,797.80

36.02

632.83

003

13,390.06

14.60

916.71

004

10,428.43

19.99

521.58

005

10,109.21

17.87

565.65

006

6,833.93

23.03

296.65

Table 27: Saving the cost per kilometer to a user-defined attribute

PTV AG

103

Chapter 2: Network model

Note: Use formula attributes if you want the attribute Cost_per_Km to be updated
automatically when costs or link lengths change (see "Formula attributes" on page 104).
Then you need not repeat the calculation procedure in order to update the attribute. Visum
will automatically calculate the current values for you.
Each user-defined attribute has one data type. The following data types can be selected.

Bool (for example for a user-defined attribute "in scenario active", which can only be 0 or 1)
File (for example for a user-defined attribute at count locations which specifies which file
contains further information on the count location)
Formula (for automatic update of calculated attribute values) (see "Formula attributes" on
page 104)
Integer
Precise duration
Number with decimal places
Kilometers
Meters
Long text
Text
Time period
Time (for example 06:32:45)

2.3.3.1

Formula attributes

User-defined attributes of the formula type largely differ from other user-defined attributes.
They are not used to save data (they do not belong to the input attributes), but consist of an
arithmetic expression that contains other attributes. This expression is created when you
create the attribute, but can be changed later on.
The advantage of using formula attributes is that Visum automatically recalculates the formula
when one of the input values changes. Then your values are always up-to-date. Just as the
other attributes, you can also use formula attributes to graphically display data, filter data or to
perform analyses.

Example
For a PrT and PuT assignment, Visum calculates link volumes for PrT and PuT that are saved
to the attributes volume PrT [Pers] and volume PuT [Pers]. When creating a formula attribute
Advantage PrT = Volume PrT [Pers] - Volume PuT [Pers]
, you have direct access to the difference between the two volumes. This difference is
automatically updated if one of the input values changes.
Formula attributes are always numerical. When creating a formula expression, you have the
same options as for the procedure Edit attribute (see User Manual, Chpt. 2.3.8, page 176): A
formula is the sum of (a number of) subexpressions that each consist of an attribute or two
attributes combined with a binary operator. The operators available are the four basic
arithmetic operations, division in percent, raise to higher power, and minimum and maximum.
Each subexpression may be included in the amount. The formula total can additionally be
rounded or truncated.

104

PTV AG

Chapter 2.3: Attributes

There are no restrictions concerning the attributes you can use in a formula. You can use
formula attributes within other formula attributes to form more complex expressions. This
implies that you can also use brackets.

Example

2.3.4

Link formula attribute detour = length - length direct distance (subtraction)


Link formula attribute detour percentage = detour % length direct distance (division in
percent)

Time-varying attributes
The procedures DUE (see "Dynamic User Equilibrium (DUE)" on page 389) and dynamic
stochastic assignment (see "Dynamic stochastic assignment" on page 419) allow you to model
time-dependent transport supply. In Visum, time-varying attributes are used for this purpose.
Time-varying attributes only affect these assignment procedures.
Otherwise time-varying attributes override the valid value of an attribute with a deviating value
for a certain amount of time. They can thus model, for example the impact of tidal flow lane
allocation or transient road works.
Time-dependent attributes can be assigned to the following network objects.

Links
Turns
Main turns
Nodes
Main nodes

For these network objects, only specific attributes can be time-varying, and the deviating value
of the attributes is not relevant to all procedures. The table 28 gives an overview of which
attributes can be time-varying in which assignment procedures. For details, please refer to the
description of the dynamic stochastic assignment (see "Dynamic stochastic assignment" on
page 419) and DUE (see "Dynamic User Equilibrium (DUE)" on page 389).
Network object

Time-varying attribute

Links

Out capacity PrT


Capacity PrT

Dynamic Stochastic Assignment

DUE
X

Toll-PrTSys

X
X

v0 PrT

TSysSet

AddValue 1-3
AddValue-TSys
Turns

Capacity PrT

ICA final capacity


t0 PrT

TSysSet

Table 28: Time-varying attributes and their allocation to assignment procedures

PTV AG

105

Chapter 2: Network model

AddValue 1-3
Main turns

Capacity PrT

t0 PrT

TSysSet

AddValue 1-3
Nodes

Capacity PrT

t0 PrT

AddValue 1-3
Main nodes

Capacity PrT

t0 PrT

AddValue 1-3
Table 28: Time-varying attributes and their allocation to assignment procedures

The example in table 29 illustrates the effect of time-varying attributes using the example of the
Dynamic Stochastic assignment. The upper image shows the volumes and the capacity PrT on
the links in time period from 5 am to 7 am. The lower image shows the volumes and the
capacity PrT in the time period from 7 am to 9 am (a constant time series has been used here
to simplify the comparison of both conditions, so that the traffic supply is the same in both of
the time intervals).

The links 11 - 41 and 41 - 40 are charged with the full capacity of 800.
Table 29: Impact of time-varying attributes in the Dynamic Stochastic assignment

106

PTV AG

Chapter 2.4: Subnetwork generator

With the aid of a time-varying attribute for the capacity PrT on the two links (11-41 and 41-40), both links
are charged with a reduced capacity of 100. Therefore, the volumes of the links are lower.
Table 29: Impact of time-varying attributes in the Dynamic Stochastic assignment

2.4

Subnetwork generator
With the Subnetwork generator add-on module, a subnetwork together with the associated
partial matrices can be generated from the overall network in such a way that, generally
speaking, comparable assignment results are obtained for the subnetwork.
The subnetwork is generated on the basis of the following rules:

PTV AG

The basis are all active links and all active line routes.
Apart from that, the following network objects are transferred to the subnetwork:
All From nodes and To nodes of the active links.
All junction editor / junction control data for nodes with at least one leg in the
subnetwork
Turns whose From link and To link belong to the subnetwork
All connectors at a node located in the subnetwork
All zones with connectors at a node located in the subnetwork
All PrT paths that belong to path sets
All count locations located on active links
All active POIs and, if applicable within the subnetwork; all references to nodes, links,
POIs, stop points and stop areas are copied
All screenlines

107

Chapter 2: Network model

All existing toll systems with at least one active link


All active territories
All main nodes if all associated partial nodes are active, and all associated main turns
All stops that have at least one stop point on an active line route or a stop area within
the active area are transferred in full (inclusive of all stop points and stop areas).
Moreover, nodes (of the stop areas or stop points) referenced by the stop and, where
applicable, connectors and zones connected to them are transferred.
All active line routes, cut off if necessary
All stop points and links of cut-to-length line routes
All lines that have at least one active line route
All main lines with at least one line included in the generated subnetwork
All line route items of the active line routes
All time profiles and time profile items of the active line routes
All vehicle journeys, vehicle journey sections and journey routes of active line routes
All coordination groups which are with their time profiles and extension completely
within the subnet.
All turn standards and block item types

In addition, the following network objects are transferred from the entire network to the
subnetwork:

108

Demand segments
Modes
Transport systems
Link types
Main zones
Calendar periods
Valid days
Fare zones
Ticket types
Directions
Operators
Vehicle combinations
Vehicle units
Surfaces
Demand matrices
Time series
Demand time series
Activities, activity pairs, activity chains *
Person groups, structural properties *
Demand strata *
Skim matrices
Procedure parameters

PTV AG

Chapter 2.4: Subnetwork generator

* when activating option Include the demand model in the subnetwork

Demand matrices
Apart from the selected partial matrices (see User Manual, Chpt. 2.44, page 726), all other
matrices that exist in the original network are saved to the subnetwork. The values of these
matrices are set to zero. In order to indicate that they are part of the subnetwork, a suffix is
attached to the matrix file names. If the version file contains references to matrices, they
are updated accordingly.
Example
Subnetwork version name: tgen_ver
Matrix file name in the original network: car.mtx
Matrix file name in the subnetwork: car_tgen.mtx

The subnetwork generator considers the paths of an existing assignment and generates new
zones at the networks interfaces at which traffic flows enter or leave the network. These
virtual boundary zones (subnetwork cordon zones) are added to the partial matrices of the
demand segments so that no traffic demand in the subnetwork is lost.

PrT demand matrices


Cordon connectors are generated at all boundary nodes. Boundary nodes are nodes at
which active and passive links meet, meaning at which at least one link is not included in
the subnetwork. A subnetwork cordon zone is generated for each generated connector.
Visum can then supplement the demand matrix using the paths. This requires performing
an assignment.
PuT demand matrix
Boundary stop points are the first and last stop points of the active line routes and all stop
points at which transfer events to passive line routes take place. Generated connectors are
created at each stop area of a boundary stop point. A subnetwork cordon zone is generated
for each generated connector. This requires performing an assignment. Alternatively, two
kinds of stop point matrices can be generated.
On path leg level
For each partial route that is assigned to an active line route, a subnetwork cordon zone
is generated each at the start and end stop point. The volume of the route is recorded
as a demand between the respective zones, which means it emerges as many times in
the new matrix as there are partial routes within that route.
On path level
For each route a cordon zone is generated for the first stop point of all active line routes
(start). If the route is no longer active or if a partial route is followed by a walking link
which leads across a passive link, a subnetwork cordon zone is created at the last stop
point of the last active partial route (end). The demand is recorded between the start
and the end. As soon as the route is active again, a subnetwork cordon zone is firstly
generated at the first stop point of the first active partial route again etc.

If all line routes of all links are active, the total of the stop point matrix equals the total of the
demand matrix.
For matrices on path level and path leg level the following applies: If the PuTAux transport
system is used in a PuT assignment, the subnetwork generator manages routes that contain
PuTAux as follows:

PTV AG

109

Chapter 2: Network model

If there is a passive link on a route section that uses PuTAux, a subnetwork cordon zone is
generated at the From node of this link. As soon as the next active link is found, the
subnetwork generator creates another subnetwork cordon zone at the From node of that
link. The volume is transferred as demand data from one subnetwork cordon zone to the
next one.
In contrast, the following applies to the PuT Walk transport system: If there is at least one
passive link within a walk link, subnetwork cordon zones are created at the last stop point
before the walk link and at the next stop point after the walk link and not at the nodes of the
passive link, as for PuTAux.

The example in illustration 46 illustrates the differences. The Numbering of cordon zones
with offset option has been selected in order to clarify the connection with the nodes. The
offset specified is 10.
Walk link via active links

Zone

12

External zone

Path leg on active line route

Node

Walk link (via at least one passive link)

Stop point

Pathleg on passive line route


Stop point matrix (regarding path legs)

12

13

14

15

16

17

18

Stop point matrix:


1

12
13
14
15
16
17
18

12 13 14 15 16 17 18
50
50
50
50

Stop point matrix (regarding paths)

12

14

15

18

8
Stop point matrix:
12
14
15
18

12 14 15 18
50
50

Illustration 46: Generating a subnetwork with stop point matrices regarding path legs and stop point
matrices regarding paths

Procedure parameters
All procedure parameters that exist in the original network are transferred to the
subnetwork. In order to indicate that they are part of the subnetwork, a suffix is attached to
the files that store procedure parameters.

110

PTV AG

Chapter 2.5: The surface data model in Visum

2.5

The surface data model in Visum


In Visum boundaries can be shaped for the network objects zones, main zones, toll systems,
territories, main nodes, GIS objects and POIs (polygons). Polygons describe the location and
extent of network objects. Based on freely definable points and edges that connect these
points, they are defined as surfaces independent of the network and allocated to the respective
network objects via the SurfaceID attribute. The surfaces are displayed in the Visum surface
model.

2.5.1

Tables in the surface model


The Visum surface model consists of the following seven tables. In these tables, the surfaces
of all network objects are displayed. The tables are explained with the aid of an example.

Point
Edge
Edge item
Face
Face item
Surface
Surface item

Note: In Visum, you can save polygons together with the network object type using them to a
network file (see User Manual, Chpt. 1.4.6, page 48). However, thereby all polygons are
saved, independent of whether they were used for an object of the type specified or not.

Example
In the following example, the seven tables are displayed and explained for a network that
contains three main nodes with surfaces.
The network includes the three main nodes with the IDs 2, 3 and 4. These main nodes are
allocated via the SurfaceID attribute to the surfaces with the IDs 866, 867 and 868 (table 30).
* Table: Main nodes
$MAINNODE:NO;SURFACEID
2;866
3;867
4;868
Table 30: Table Main nodes

In the Surfaces table, all surfaces contained in the network are stored with their IDs. Since, in
the example, only the three main nodes have a surface, there are exactly three entries for the
main node surfaces in this instance (table 31).
* Table: Surfaces
$SURFACE:ID
866
867
868
Table 31: Table Surfaces

PTV AG

111

Chapter 2: Network model

Each surface is composed of one or multiple faces. The allocation of surfaces to faces is
carried out in table Surface items. In the example, the surfaces 866 and 868 have exactly one
face, whereas surface 869 has two faces. Thus, there are four faces in total with the IDs 1139,
1141, 1144 and 1145 (table 32).
* Table: Surface items
$SURFACEITEM:SURFACEID;FACEID;ENCLAVE
866;1139;0
868;1141;0
869;1144;0
869;1145;0
Table 32: Table Surface items

In the Faces table, all faces contained in the network are stored with their IDs. In this example,
there are thus four faces (table 33).
* Table: Faces
$FACE:ID
1139
1141
1144
1145
Table 33: Table Faces

In the Face items table, each face is allocated the IDs of the edges which define the face. As
you can see in table 34, the faces with the IDs 1141, 1144 and 1145 are squares each, as they
are defined by four edges. Face 1139 however, is a pentagon with five edges.
* Table: Face items
$FACEITEM:FACEID;INDEX;EDGEID;DIRECTION
1139;1;33136;0
1139;2;33137;0
1139;3;33138;0
1139;4;33139;0
1139;5;33140;0
1141;1;33145;0
1141;2;33146;0
1141;3;33147;0
1141;4 33148;0
1144;1 33160;0
1144;2 33161;0
1144;3;33162;0
1144;4;33163;0
1145;1;33164;0
1145;2;33165;0
1145;3;33166;0
1145;4;33167;0
Table 34: Table Face items

The table Edges contains all edges which are required for the description of the face items.
Each edge is defined by a start point and an end point, which bear the attribute names
FromPointID and ToPointID in the table (table 35).

112

PTV AG

Chapter 2.5: The surface data model in Visum

* Table: Edges
$EDGE:ID;FROMPOINTID;TOPOINTID
33136;9449;9450
33137;9450;9451
33138;9451;9452
33139;9452;9453
33140;9453;9449
33145;9458;9459
33146;9459;9460
33147;9460;9461
33148;9461;9458
33160;9473;9474
33161;9474;9475
33162;9475;9476
33163;9476;9473
33164;9477;9478
33165;9478;9479
33166;9479;9480
33167;9480;9477
Table 35: Table Edges

In the Points table, all points are displayed which in turn define the edges. Each one contains
information on the coordinates (XCoord and YCoord). This establishes the spatial reference of
the surface to the network (table 36).
* Table: Points
$POINT:ID;XCOORD;YCOORD
9449;3456991.5413;5430055.0204
9450;3456991.5413;5430004.3885
9451;3457052.3873;5429991.7699
9452;3457070.0872;5430048.9542
9453;3457026.8560;5430057.9988
9458;3458808.0227;5431086.8027
9459;3458821.3171;5431061.4225
9460;3458848.5102;5431078.9469
9461;3458835.5180;5431101.9100
9473;3456956.4483;5430005.5296
9474;3456948.8422;5430060.3735
9475;3456887.1928;5430052.7674
9476;3456903.2057;5429996.7225
9477;3456896.8005;5430097.6033
9478;3456938.0336;5430071.1821
9479;3456961.6525;5430097.6033
9480;3456945.2393;5430125.2254
Table 36: Table Points

No intermediate points were generated in the example. The table is therefore empty (table 37).
* Table: Intermediate points
$EDGEITEM:EDGEID;INDEX;XCOORD;YCOORD
Table 37: Table Intermediate points

PTV AG

113

Chapter 2: Network model

2.5.2

Multi-part surfaces
A surface can be made up of several faces (multi-part surfaces). Generally, a multi-part surface
is defined by a set of so-called faces. Each face is a polygon with a sign. This is positive, if
coordinates encircle the polygon anti-clockwise and negative, if the coordinate sequence is
clockwise. Positive faces are thus digitalized anticlockwise, negative faces clockwise. This
way, the type of polygon is clearly defined when interactively modifying polygons in the network
display. This orientation of a face is thus a significant object feature. Positive faces add to the
surface, negative surfaces subtract from it (holes).
a n ti- c

c lo c

kwi

lo c k

w is e =
p o s it
iv

se =
neg

a t iv

anti-clockwise
= positive

Illustration 47: Positive and negative surfaces

Visum automatically normalizes the definition of any surface it encounters. Faces never
intersect and a positive face will always (directly) contain only negative faces and vice versa.

What is a normalized surface and why does it need to be normalized?


Running geometrical operations (like Intersect or Territory indicators) efficiently on complex
surfaces requires the use of a normalized representation. The table 38 shows some examples
for the normalization of surfaces.
Specified surface

Normalized shape of the surface

Two separate faces

OK the surface remains unchanged

Table 38: Examples of the normalization of surfaces

114

PTV AG

Chapter 2.5: The surface data model in Visum

Specified surface

Normalized shape of the surface

Two overlapping faces

not OK both faces have been merged

A face with a hole

OK the surface remains unchanged

A face with a hole which intersects the


boundary of the surface

not OK the hole is omitted and the face


adjusted

A face with an intersecting boundary

not OK the negative part is deleted

Table 38: Examples of the normalization of surfaces

A surface is thus "normalized if the following conditions are met:

PTV AG

None of the faces of the same orientation overlap. This means


all positive faces are separated (criterion 1a).
none of the negative faces intersect nor touch the open plane (criterion 1b).
none of the faces have intersecting boundaries (criterion 2).

115

Chapter 2: Network model

The simple example of the area calculation suffices to understand why a normalized
representation facilitates geometrical operations. The area of normalized surfaces results
directly from the sum of the areas of its faces. The sign depends directly on the orientation.
Without normalization, the areas of all occurring intersections of the faces would have to be
subtracted from the result. This would imply a significant increase in computation time.
Computation time particularly increases because the mere determination of the intersection of
sets with multiple overlaps is a complex algorithmic procedure.

When does the program normalize?


Normalized surfaces are a prerequisite for efficient use of polygons in various geometric
calculation procedures. This is why this normalization is automatically performed during
interactive digitalization and editing of polygons. The examples above show surfaces that can
be inserted interactively just as they are displayed in the left column. However, when leaving
the Edit shape mode, Visum automatically normalizes the surfaces. When loading surfaces
from network or shape files, it is checked whether they are normalized or not. If required, the
input data is then normalized. If polygons have already been normalized or the data is not
required for geometrical calculation procedures (e.g. POI layers that merely serve as a
background), you can optionally leave out the normalization check and so reduce import time.
Note: However, if non-normalized surfaces that were originally only meant for background
display are later on used in calculation procedures, this can lead to erroneous results, as
normalization is required for such operations. If you are not sure whether a surface has been
normalized or not, make sure you normalize it, if required (see User Manual, Chpt. 2.10.6,
page 235).

How accurate is the normalization (for experts)?


The order in which the faces of a surface are defined is crucial to the normalization. In the
network file, this order is defined by table Surface items.
The polygon of a face needs to be preprocessed if its boundary intersects (see table 38,
example 5). In this case, the face is split into non-intersected segments. This segmentation is
done in such a way that the components do not intersect either. The orientations of the
segments do not change, i.e. a scroll like the one in table 38, example 5 is interpreted as a
negative face. The positive and the negative polygons determined in this way are merged with
the intermediate result of the faces considered before. If no boundaries intersect, segmentation
is not necessary. The specified polygon and the intermediate result of the faces considered
before can be merged directly.
During this aggregation, faces sometimes have to be merged. This is, for example, the case in
table 38, example 2, where two positive faces are merged. It can however also happen if faces
are omitted and other faces change their shape. This is, for example, the case in table 38,
example 4.
This approach particularly implies that the first face must not have a negative orientation.
Should this be the case, criterion 1 b) immediately takes effect, i.e. the face is dismissed.
The question whether the orientation of the polygon of a face matches the enclave attribute of
its surface item needs special attention. Here, information might be inconsistent when reading
networks. In this case, the enclave feature wins, i.e. the orientation of the polygon is inverted
where required. The advantage of this rule is that by editing just one attribute in the network
file, a positive polygon face can be turned into a negative one and vice versa.

116

PTV AG

Chapter 2.5: The surface data model in Visum

2.5.3

Sharing points between surfaces


Besides normalization, which is used to eliminate intersecting polygon parts (see "Multi-part
surfaces" on page 114), there is another procedure used for surfaces. It is called
harmonization. During harmonization, several points, edges or polygon faces are identified that
represent the same object. These can be now combined to one object for the polygons and
managed together. This concept is illustrated in the following simple example:
Let us assume a study area and its surrounding are modeled in a Visum network. Both areas
are modeled as territories, so they are assigned territory indicators. The edge of the study area
normally corresponds to the hole in the surface of the surrounding. There are two options for
modeling this:

The study area is a one-piece surface. The surrounding consists of two surface areas, the
outer, positive outline and a hole. The gap has the same edge points as the study area, but
its own face object, edges, points and intermediate points. This is because during
digitization of the surrounding, the existing edge points of the study area are snapped, but
the option Merge snapped points has not been activated. If one of the two surfaces is
digitized again later on, this does not affect the other surface. The edges of the two
surfaces do not remain congruent, but a gap or an overlapping area (or both) is created.
The study area consists of a one-piece surface that is also used as its negative face. This
is because during digitization of the surrounding, the existing edge points of the study area
are snapped and the option Merge snapped points has been activated. If one of the two
surfaces is digitized again later on, this will affect the other surface in terms of the face that
is used by both. The edges of the two surfaces still remain congruent, even after changes
have been made.

Which type of modeling is best suited depends on the individual case. However, it is always
helpful to combine points of the same coordinates into an object, if the surfaces have the same
borders. If you are working with larger models, the aspect of saving memory space may also
play a role. Since if points (intermediate points, edges, faces) are combined into an object, less
memory space is required.
You can also combine all points with identical coordinates of an existing network later on (see
User Manual, Chpt. 2.10.7, page 236).

PTV AG

117

Chapter 2: Network model

118

PTV AG

Demand model
One of the main uses of Visum is modeling demand. Demand modeling deals with traffic
conditions. The most common travel forecasts analyze the daily travel behavior of people.
These forecasts provide answers to the questions, when, how often, where and how do people
travel.
Visum offers three demand modeling procedures.

Standard 4-step model (see "Standard 4-step model" on page 126)


EVA (see "EVA model for passenger demand" on page 132)
Tour-based model (see "Activity chain based model (tour-based model)" on page 161)

The result of these procedures are matrices, which contain trips between the origin and
destination zones of the network. These matrices are assigned to one or more demand
segments. Assignment takes place on the basis of demand segments (see "User model PrT"
on page 211 and "User model PuT" on page 429).
It is not mandatory to create a separate demand model in Visum, which calculates the matrices
for the assignment. You can also use and assign matrices from external sources. Therefore, a
complete demand description in Visum (that of course allows you to calculate an assignment)
first only consists of the following elements:

the demand in form of a matrix (see "Matrices" on page 120)


temporal distribution of the demand by specifying a time series (see "Time series" on
page 121). Specifying a time series is, however, only necessary for dynamic PrT
assignments and PuT assignments. The demand distribution is ignored in the case of static
PrT assignments.
the allocation of matrices to one or more demand segments (see "Demand segments" on
page 120).

There are several demand objects (see "Demand objects" on page 119) that allow you to
display the demand within the Visum data model. Which of these demand objects are applied
in your model, depends on the type of demand modeling in your network.

Subjects

3.1

Demand objects
Demand modeling procedures
Displaying and editing matrices
Matrix correction

Demand objects
A demand model consists of a set of demand objects which contain all relevant demand data,
for example, the origin and destination of demands and the number of them in demand
matrices. The demand object types in Visum are described below.

PTV AG

Matrices

119

Chapter 3: Demand model

Demand segments
Time series
Demand model structure
Person groups
Activities, activity pairs, activity chains
Demand strata

In addition, the EVA and tour-based demand models also contain the demand structural
properties (see "Structural properties" on page 132 and "Tour-based data model" on
page 161).

3.1.1

Matrices
Matrices are one of the most important components of demand models. There are several
matrix types:

Demand matrices are used to show the transport demand between origin and destination
zones.
Skim matrices show the origin-destination zone skims, e.g. the travel time.
Weighting matrices are only used to calculate the Weighting step of EVA-P demand models
(see "EVA model for passenger demand" on page 132).

In OD matrices, the demand is coded (by the number of trips) from origin zone i to destination
zone j. The temporal distribution of travel demand within the analysis period is described by a
start time and a time series that is considered during PuT assignment and dynamic PrT
assignments (see "Time series" on page 121). The demand distribution is ignored in the case
of static PrT assignments.
The Matrix editor integrated in Visum allows you to process existing matrix data and perform
calculations based on the gravity approach (see "Gravity model calculation" on page 174).
In Visum, OD matrices and time series are independent objects which can freely be allocated
to demand segments for assignment. This means that you can also use a matrix for more than
one demand segment.
Note: It is not mandatory to create a separate demand model in Visum, which calculates the
matrices for the assignment. You can also use and assign matrices from external sources.

3.1.2

Demand segments
A demand segment is a demand group or class, which is allocated in one step to a network,
because the demand is homogeneous to the group. Examples for a demand segment could be
pupils or commuters. The journey times from origin zones to destination zones are calculated
per demand segment (see "Demand segments" on page 36).
Demand segments are different from demand strata (see "Demand strata" on page 124).
Demand strata contain demand groups for the steps trip generation, trip distribution and mode
choice of the Standard 4-step model. Another important difference is that each demand
segment is assigned to exactly one mode (for example PrT or PuT).

120

PTV AG

Chapter 3.1: Demand objects

The demand strata of a mode are generally aggregated to create demand segments. These
aggregated demand segments are then assigned to the network. Aggregation is possible since
the variables used to differentiate between the demand strata have no effect on the
assignment. Demand strata, for instance, are often distinguished by employment, e.g.
employees with a car and non-employees with a car. If the study area has no toll roads, the
employee status plays no role for route choice during the assignment. In other words:
Everyone chooses the same route between the origin and destination zone, irrespective of
their income level. So demand strata can be aggregated to a demand segment for assignment.
To calculate an assignment, the system needs to assign each demand segment exactly one
matrix (see "Matrices" on page 120). For dynamic PrT assignments and all PuT assignments,
a demand time series must also be assigned to each demand segment (see "Time series" on
page 121). Visum establishes the link between demand and transport supply.
Notes: A possibly specified time series is ignored in the case of static PrT assignments.
A matrix can also be assigned to several demand segments. The same applies to time series.

3.1.3

Time series
The temporal distribution of trip demand over the evaluation period is described using a start
time and a demand time series. The demand time series is considered for PuT assignment and
dynamic PrT assignment. The demand distribution is ignored in the case of static PrT
assignments (see "Temporal distribution of travel demand" on page 5 and "Time reference of
the demand (time series)" on page 86).
Note: A time series can also be assigned to several demand segments.
There are two types of standard time series:

3.1.4

Time series of matrix numbers, i.e. selection of several matrices that form the time series.
proportional time series of a demand matrix
with distribution of travel demand in time intervals (in percent)
if required modified per pair of zone type relation

Demand model structure


Demand models are a particular kind of Visum demand objects to which the other demand
objects (person groups, activities, activity pairs and activity chains, demand strata, structural
properties) are assigned and which allow to define and store various calculation models for
demand modeling in Visum (see "Transport demand model" on page 3).
A demand model has the following attributes:

PTV AG

Attribute

Description

Code (Key)

Code (any string), for example EVA-P

Name

Name of the demand model, for example EVA-P model

Type

Type of calculation model (Standard 4-step, EVA passenger demand or Tourbased model)

Mode codes

Abbreviation of the modes of the demand model

121

Chapter 3: Demand model

3.1.5

Person groups
The population living in the planning area is broken down into so-called behaviorhomogenous groups. The traffic behavior of the different groups should be clearly different,
but within the individual groups it should be as homogenous as possible.
This documentation uses examples in which the person groups are normally broken down
according to the criteria employment/education and motorization. The following table shows a
division into groups with homogenous behavior and their codes (Schmiedel 1984).
Employees with car available

E+c

Employees without car

E-c

Not-employed with car available

NE+c

Not-employed without car

NE-c

Apprentices

Appren

Students 18 yrs and older

Stud

Pupils from secondary school

SPup

Primary school pupils

PPup

Children under six

Child

The demand object person group is described by the following attributes:


Attribute

Description

Code (Key)

Code (any string), for example Stud

Name

Name of person group, for example students

DemandModelCode

Abbreviation of the demand model the person group belongs to (any string), e.g.
DEFAULT

When using the Standard 4-step model, generally only one single person group is required, i.e.
there is a 1:1 relation between activity chain and demand stratum.

3.1.6

Activities, activity pairs, activity chains


The demand model is based on the assumption that trip purposes or external activities cause
mobility. The examples given in this manual use the activities listed in the table below. They are
derived from traffic surveys, e.g. from KONTIV 89, whereby the activity of education has been
differentiated.

122

Work

Shopping

Education: vocational school

Education: university

Education: secondary school.

Education: primary school

Recreation

PTV AG

Chapter 3.1: Demand objects

Home

The demand object activity is described by the following attributes:


Attribute

Description

Code (Key)

Code (any string), for example W

Name

Name of the activity, for example housing

IsHomeActivity

This Boolean attribute is true (= 1) if the activity is the starting point and end point
of an activity chain. This is typically the case for the activity Home.

DemandModelCode

Abbreviation of the demand model the activity belongs to (any string), e.g. EVAP.

Note: Activities are optional and can be defined interactively only for EVA and tour-based
models. In case of Standard 4-step models one activity corresponds to exactly one activity
pair.
An activity pair corresponds to the trip between two successive activities in the daily routine of
a person.
The demand object activity pair is described by the following attributes:
Attribute

Description

Code (Key)

Code (any string), for example HW

Name

Name of the activity pair, for example home - work

DemandModelCode

Abbreviation of the demand model the person group belongs to (any string), for
example DEFAULT.

The following attributes describing activity pairs are only relevant for EVA models.
Attribute

Description

OrigActivityCode

Code of the activity where the trip starts, for example H (home)

DestActivityCode

Code of the activity where the trip ends, for example W (work)

OD type

Direction of the activity pair in terms of the home activity


The following values are possible.
1 - Origin activity is home activity (for example home - work)
2 - Destination activity is home activity (for example shopping - home)
3 Neither origin nor destination activity are home activity (for example others
others).
By default the value of the attribute is determined by the attribute
IsHomeActivity of origin and destination activity, but can also be overridden
manually. It has an influence on the calculation in trip generation and trip
distribution (see "EVA trip generation" on page 135 and "EVA trip distribution
and mode choice" on page 152).

An activity chain describes a sequence of typified activity pairs. For example, the chain home
work shopping home (HWOH). Such a sequence of activity pairs implies trips, in this
example here three different trips (HW, WO, OH).
The following attributes describe the demand object activity chain.

PTV AG

123

Chapter 3: Demand model

Attribute

Description

Code (Key)

Code (any string), for example HWH

Name

Name of the activity chain, for example home work home

ActivityCodes

Comma-separated list of activity codes

DemandModelCode

Abbreviation of the demand model the person group belongs to (any string), for
example DEFAULT.

In the tour-based demand model, the average mobility program of persons is described by
activity chains. The Standard 4-step model and the EVA model allow single-element activity
chains only. So an activity chain corresponds directly, i.e. 1:1, to the activity pair.

3.1.7

Demand strata
The demand stratum constitutes the basic demand object for calculating trip generation, trip
distribution and mode choice. It links an activity chain with one or several person groups (in the
tour-based model with exactly one person group). The pointers to activity chains and person
groups in the Standard 4-step model are optional.
The correlations between demand objects can be depicted graphically as follows (see
"Correlations between different demand objects" on page 124).
Activity
e.g. Work
1

OrigActivity n

n DestActivity

Activity Pair
e.g. HW
n
m

Standard-4-Step Model
and EVA Model:
1 : 1 (=Activity Pair)

Activity Chain
e.g. HW-WH

Person group or
Household group
Person Group
e.g. E+c

n
n

m
Demand Stratum
e.g. HW-WH x E+c

Illustration 48: Correlations between different demand objects

The demand object demand stratum has the following attributes.

124

Attribute

Description

Code (Key)

Code (any string), for example HWH Stud

ActChainCode

Activity chain code (optional)

DemandGroupCodes

Person group codes (optional)

Name

Name of demand stratum, for example student-shopping or


employee+car home-shopping-home

PTV AG

Chapter 3.2: Demand modeling procedures

Attribute

Description

DemandModelCode

Abbreviation of the demand model, for the respective demand


stratum, for example DEFAULT

DistribMatrixNumber

Number of demand matrix to which the result of the distribution for


this demand stratum is stored (optional)

DemandTimeSeriesNumber

Number of demand time series for temporal distribution of demand


(optional).

The following attributes describing demand strata are only relevant for EVA models.
Attribute

Description

Origin Structural Property Codes Origin of the structural property codes

3.2

Destination Structural Property


Codes

Destination of the structural properties codes

Balancing

Indicates the demand stratum (origin-destination type 3) in which


balancing takes place

Quantity as potential

This Boolean attribute describes whether the productions or


attractions of the demand stratum impact as potentials in Trip
distribution/Mode choice (=1) or only have to meet the constraints
(=0).

Marginal totals type origin


Marginal totals type destination

Type of marginal totals of the constraint on origin or destination


side

Marginal totals min factor origin


constant
Constraints max factor origin
constant
Constraints min factor
destination constant
Marginal totals max factor
destination constant

This Boolean attribute describes, whether the lower or upper limit


of the production and attraction is constant (=1) or zone-dependent
(=0).

Constraints min factor origin


Constraints max factor origin
Constraints min factor
destination
Constraints max factor
destination

Factor for the upper or lower limit of production or attraction.

Demand modeling procedures


Information on the demand within the planning area is required for the analysis of
transportation networks. Demand matrices can be determined partially through surveys. That
is why mathematical models are used to reproduce real demand ratios, which calculate the
traffic flows between the zones of the planning area on the basis of the structure and behavior
data, the spatial utilization structure and the transport system. Another function of such a
model is the provision of prognoses and scenarios.
Visum currently offers three procedures for demand modeling:

PTV AG

125

Chapter 3: Demand model

Standard 4-step model


EVA model for passenger demand
Activity chain based model (tour-based model)

There are also the following functions available to calculate the transportation demand:

3.2.1

Estimate gravitation parameters (KALIBRI)


Gravity model calculation
Iteration

Standard 4-step model


The first three steps of the 4-step model, trip generation, trip distribution and mode choice, are
usually carried out sequentially in the Standard 4-step model successively. As illustration 49
shows, skim matrices resulting from assignment are incorporated into the model stages of Trip
distribution and Mode choice. Due to this cyclical dependence the process covering all four
steps (including Assignment) is repeated until the result fulfills the stop criterion, which usually
is the stability of the demand matrices or the impedances in the network. You can call the
procedure run manually or use Go to the Procedure (see "Go to procedure" on page 182).

126

PTV AG

Chapter 3.2: Demand modeling procedures

Per demand stratum

production
rates

zone
attributes
(inhabitants,
jobs)

Trip generation
skim
matrix

utility
function

production
& attraction
(per zone)

Trip distribution
skim matrix
per mode

utility
function

demand
matrix

Mode choice

Per
demand
segment

demand
matrix

Assignment

demand
matrix

demand
matrix

Assignment

demand
matrix

Assignment

Illustration 49: Integrated 4-step demand model in Visum

Moreover, the convergence speed can be improved by averaging matrices or impedances


after the assignment by means of several iterations before using them for the next iteration of
the demand model. This can be done with the operations Method of successive averages over
matrices and Method of successive averages over attributes (see "Method of successive
averages over matrices" on page 183 and "Method of successive averages over attributes" on
page 184).
As variant of the classical 4-step model Mode choice can be calculated in several steps instead
of one step (Nested Logit). You can optionally add a departure time after mode choice. The
illustration 50 shows as an example the procedure in an extended demand model.

PTV AG

127

Chapter 3: Demand model

Illustration 50: Extended 4-step model

In the normal case carry out each of the operations trip generation, trip distribution and mode
choice for all demand strata of the model. For special purposes, however, they can also be
carried out for individual demand strata if the required input attributes are known.
If necessary, operations on matrices may be fitted in between the individual stages, for
example in order to prepare skim matrices (e.g. setting the values on the matrix diagonal) or to
add externally predetermined demand data (e.g. through-traffic) (see "Displaying and editing
matrices" on page 184).

3.2.1.1

Trip generation

In that stage for each zone and each demand stratum the origin and destination volumes are
calculated. These parameters are also called productions and attractions. The productions
either correspond to the actual origin traffic of the zone i.e. the number of trips starting there,
or the attractiveness of the zone for the demand stratum, meaning they have an influence on
the probability of trips starting in that zone with the next Trip distribution procedure. Which of
the two cases applies can be determined by a procedure parameter of Trip distribution. The
same holds for destination traffic.
The productions of a demand stratum in a zone depend on its structural or demographical
indicators describing the intensity of the production activity. For the production activity Home
the number of inhabitants of a zone, if necessary, disaggregated into age, income and/or car
availability can be used. For the production activity Work the number of jobs may be
appropriate, perhaps broken down into different sectors. For such skims user-defined zone
attributes are the best. First, production Qi of zone i is calculated with the help of a formula,
Qi = g SGg (i )
g

whereby SGg is summed up across all structural properties. SGg(i) corresponds to the value of
SGg in zone i. The coefficient g is a production rate that shows the number of trips per

128

PTV AG

Chapter 3.2: Demand modeling procedures

structural property unit. They specify the production rates per demand stratum and zone
attribute used. The same calculation is performed for the attraction Zj.
In most applications the total production of a demand stratum (added up over all zones)
corresponds to the total attraction.

Qi = Z j
i

If equality has not already been the outcome of the attributes and production rates used, it can
be set by means of a procedure parameter whether all productions and attractions have to be
scaled so that their totals are equal. As reference values you can predetermine total
productions, total attractions or the minimum, maximum or mean value of both parameters.
You can limit calculation to the active zones. This might be useful in cases where the network
model covers both the actual planning area and its surrounding sub network cordon zones. If
you only want to calculate planning area-internal trips by means of the demand model, first of
all define a filter for the zones of the planning area only. Proceed in a similar way if the
production rates are not uniform for all zones. Break the zones down into groups of
homogeneous production rates and insert the operation trip generation for each of the groups
into the process. Prior to each such operation set a filter for the zones of that group (operation
Read filter (see User Manual, Chpt. 2.7.5.2, page 208)) and calculate trip generation only for
the respective active zones.
For each zone the results of trip generation are stored per demand stratum in the zone
attributes productions and attractions.

3.2.1.2

Trip distribution

The productions and attractions calculated in the operation trip generation only determine the
constraints of the total demand matrix of a demand stratum. The elements of the matrix
themselves are calculated in the operation trip distribution. On the one hand, the allocation of
a certain destination zone to a given origin zone is based on its attractiveness for the demand
stratum (measured by its destination demand = attractions), on the other hand the impedance
of the trip from origin to destination zone is vital (measured by the skim matrices for journey
time, fares and other elements of generalized costs).
These input data being available, a gravity model is formulated and solved (see "Gravity model
calculation" on page 174).
Notes:
Origin and destination traffic of the individual zones have to be available per demand
stratum as zone attributes productions and attractions.
To each demand stratum for which Trip distribution is to be calculated a demand matrix
has to be allocated into which the results are stored.
The parameters for the gravity model can be estimated beforehand (see "Estimate
gravitation parameters (KALIBRI)" on page 173).

PTV AG

129

Chapter 3: Demand model

3.2.1.3

Mode choice

The operation Mode choice breaks down the total demand (total demand matrix) into the
individual transport modes per demand stratum (for example PrT, PuT) based on modespecific impedance skims (for journey time, costs, etc.).
First of all for each mode m the utility is calculated as a linear combination of the impedance
parameters.
U ijm = g cijmg
g

Whereby
The impedance of the cost type g for the trip from zone i to zone j by mode m.

cijmg

The respective shares of the trips of each relation result from the utilities of the different modes.
Hereby, you can choose between several distribution functions (see "Gravity model
calculation" on page 174). As an example see below the calculation for the Logit model.

p ijm =

c U ijm

c U ijk

k
Tijm = p ijm Tij
whereby Tij is the total number of trips of the demand stratum in the relation i-j, Tijm is the
number of trips made by mode m and c is a procedure parameter.
There are two types of demand strata.

Those referring directly to a demand matrix allocated to one single demand segment or
several demand segments
Those whose demand matrix is not related to any demand segment

No mode choice will be calculated for demand strata referring directly to a matrix with demand
segment(s).
For demand strata whose demand matrix is not related to any demand segment it is
determined per mode to which demand matrix the demand allocated to that mode has to be
added in mode choice.

3.2.1.4

Nested Mode Choice

For nested mode choice, the total demand (total demand matrix) per demand stratum is
distributed to the transport modes defined in the network (for example car PrT, bus PuT), using
mode-specific skims of several stages (illustration 51).

130

PTV AG

Chapter 3.2: Demand modeling procedures

Illustration 51: Modeling through decision tree

For the Logit model (mode choice), the decision model determines the utility of a leaf node as
usual through a linear combination of skim matrices of the respective mode. For a nest node,
the utility consists of two components:

Nest utility that does not depend on the individual sub-node, e.g. fare.
Summary of individual utility of all sub-nodes, e.g. travel time.

This leads to

As a result, the procedure calculates a demand matrix for each leaf node and - optionally - also
for each nest node.
For each leaf node or nest node, the calculated result can be saved to an existing skim matrix
for further analyses (Ortzar 2001, pages 228-235).

3.2.1.5

Time-of-day choice

By trip distribution or mode choice, demand matrices can be calculated which are used by
demand segments for assignments (see "Trip distribution" on page 129 and "Mode choice" on
page 130). In addition to the demand matrix further entries may be required for an assignment.
A demand segment can refer to a time series for an analysis time interval dependent
assignment.
With operation Time-of-Day Choice, a demand matrix of a demand segment can be spread
over the time intervals of a standard time series. This standard time series can then be used
as demand time series in PuT assignments or in the dynamic PrT assignments.

PTV AG

131

Chapter 3: Demand model

3.2.2

EVA model for passenger demand


The EVA model developed by Lohse at Dresden Technical University constitutes an alternative
approach to the first three stages of the classical traffic planning model (Lohse 1997). The
model differs from the above-described Standard 4-step model (see "Standard 4-step model"
on page 126) by the following features.

If trip generation and trip distribution are calculated independently, i.e. one after the other
and above all separately for each activity pair as in the Standard 4-step model, it often
happens that differences occur between the origin and destination traffic of the zones. The
EVA model links generation and distribution by an explicit constraints step to make up for
the differences.
In the EVA model trip distribution and mode choice are performed simultaneously, i.e. by
applying a one-stage discrete choice model to three-dimensional utility matrices indexed
according to origin zone, destination zone and mode.

3.2.2.1

EVA data model

The data model for EVA also comprises the relevant demand object types (see "Demand
objects" on page 119) for other models such as the additional demand object types structural
property. Compared to the standard-4-stage model, these demand objects have some
additional attributes in the EVA model. These attributes have an effect on EVA trip generation
(see "EVA trip generation" on page 135).

Activities and activity pairs


In the EVA model activities and activity pairs have the following additional attributes.
Type of demand
object

Attribute and range of


values

Meaning

Activity

IsHomeActivity
bool (0,1)

The value of 1 specifies the activity representing the road


users home. Just one activity can be specified as such.
The attribute influences the default setting of the
OrigDestType attribute for the type of demand object of
Activity pair.

Activity pairs

OD type
{1, 2, 3}

1 = Origin activity is home activity


2 = Destination activity is home activity
3 = neither origin nor destination activity are home activity

Structural properties
Structural properties are used to measure the zone attractiveness as origin or destination of a
journey, they e.g. include sales floor areas or the number of school places. Structural
properties are very simple demand objects, their only attributes are a code and a name.
Instead, you could also use user-defined zone attributes. However, defined as structural
properties, they better reflect their role in the demand model.
To each structural property SP defined in the demand model the numerical zone attribute
ValueStructuralProp(SP) in which the values of the structural property per zone can be filed
is created automatically.

132

PTV AG

Chapter 3.2: Demand modeling procedures

Demand strata
Demand strata, too, have several additional properties, particularly in connection with their
constraints. Moreover, demand strata refer to an activity pair having an origin-destination type.
Since that type determines the treatment of the demand strata in the different operations and
therefore is referred to frequently, it is called the origin-destination type of the demand stratum
itself below.

PTV AG

Attribute

Meaning and range of values

Origin Structural
Property Codes

Parameters specifying the structural potential of the demand stratum on the


origin side.
Range: set of structural properties

Destination Structural
Property Codes

As above for destination side


Range: set of structural properties

Balancing
(Balancing on the user
interface)

Value 1 specifies the demand stratum in which the differences between total
origin and destination traffic are absorbed during balancing. Just one
demand stratum can be marked as such, it has to be of origin-destination
type 3.
Range: bool (0, 1)

Quantity as potential

1 = productions or attractions also define the structural potential


(attractiveness) of the zone for the demand stratum.
0 = productions or attractions have to be kept as constraint during Trip
distribution, but do not reflect any attractiveness. Instead all zones show the
same structural potential.
Range: bool (0, 1)

Marginal totals type


origin
(Constraint Orig. on the
user interface)

Type of constraint on origin side. For origin-destination type 1 it is always


hard, in all other cases variable.
Range: {hard, weak, elastic, open}

Marginal totals type


destination
(Constraint Dest on the
user interface)

As above for destination side


Range: {hard, weak, elastic, open}

Marginal totals min


factor origin constant
(CF OMin Constant on
the user interface)

1 = ConstraintMinFactorOrig is constant, i.e. zone-independent. The value of


the ConstraintMinFactorOrig attribute of the demand stratum is applicable.
Select this option if the factor for the lower limit of the productions is equal for
all zones.
0 = ConstraintMinFactorOrig is zone-dependent. The value of the
ConstraintMinFactorOrig(DStr) zone attribute is applicable. This option
makes sense if you want to use the individual lower limits.
This attribute can only be edited if the factor has not been determined by the
selected type of constraint.
Range: bool (0, 1)

Constraints max factor


origin constant
(CF OMax constant on
the user interface)

As above for the upper limit on origin side


Range: bool (0, 1)

133

Chapter 3: Demand model

Attribute

Meaning and range of values

Constraints min factor


destination constant
(CF DMin constant on
the user interface)

As above for the lower limit on destination side


Range: bool (0, 1)

Constraints max factor


destination constant
(CF DMax constant on
the user interface)

As above for the upper limit on destination side


Range: bool (0, 1)

Constraints min factor


origin
(CF OMin on the user
interface)

Factor for the lower limit of the productions if


ConstraintMinFactorOrigConstant = 1
This attribute can only be edited if the factor has not been determined by the
selected type of constraint.
Range: floating point number 0

Constraints max factor


origin
(CF OMax on the user
interface)

As above for the upper limit on origin side


Range: floating point number 0

Constraints min factor


destination
(CF DMin on the user
interface)

As above for the lower limit on destination side


Range: floating point number 0

Constraints max factor


destination
(CF DMax on the user
interface)

As above for the upper limit on destination side


Range: floating point number 0

Zones
Due to the definition of the objects of the demand model several zone attributes are created.

134

Attribute

Subattribute

Meaning and range of values

Balance factor
Productions

Demand stratum

Weighting of demand stratum productions


This value can be included in and recalculated during trip
distribution.

Balance factor
Attractions

Demand stratum

Weighting of demand stratum attractions


This value can be included in and recalculated during trip
distribution.

Constraints min factor


origin

Demand stratum

Factor for the lower limit of the productions if


ConstraintMinFactorOrigConstant = 0
This attribute can only be edited if the factor has not been
determined by the selected type of constraint.
Range: floating point number 0

Constraints max factor


origin

Demand stratum

As above for the upper limit on origin side


Range: floating point number 0

Constraints min factor


destination

Demand stratum

As above for the lower limit on destination side


Range: floating point number 0

PTV AG

Chapter 3.2: Demand modeling procedures

Attribute

Subattribute

Meaning and range of values

Constraints max factor


destination

Demand stratum

As above for the upper limit on destination side


Range: floating point number 0

Number of persons

Person group

Number of inhabitants of the person group in zone


Range: integer 0

Structural property
value

Structural
property

Value taken by the structural property in zone


Range: floating point number 0

Mobility rate

Demand stratum
Person group

Specific traffic demand of a person group for the demand


stratum. Only effective if MobilityRateConstant(DStr) =
0 in the procedure parameters of EVA trip generation.
Range: floating point number 0

Production rate

Demand stratum
Structural
property

Production rate of structural property for the demand


stratum on origin side. Only effective if
ProductionRateConstant(DStr) = 0 in the procedure
parameters of EVA trip generation.
Range: floating point number 0

Attraction rate

Demand stratum
Structural
property

As above for destination side


Range: floating point number 0

Study area factor home

Demand stratum
Person group

Remaining share of home trips of the person group for


the demand stratum. Only effective if
StudyAreaFactorHomeConstant(DStr) = 0 in the
procedure parameters of EVA trip generation.
Range: floating point number 0

Study area factor origin

Demand stratum
Structural
property

Effective share of the structural property for the demand


stratum (on origin side). Only effective if
StudyAreaFactor ProductionConstant(DStr) = 0 in the
procedure parameters of EVA trip generation.
Range: floating point number 0

Study area factor


destination

Demand stratum
Structural
property

As above for destination side


Range: floating point number 0

3.2.2.2

EVA trip generation

In the EVA model and Standard 4-step model, productions and attractions are calculated
similarly, namely based on demographic (number of inhabitants) and structural (jobs, size of
retail sales floor, ) parameters as well as on mobility rates (taken from statistical surveys on
traffic behavior). It is performed separately for each demand stratum, which means for each
activity pair and its major person groups.
In EVA trip generation productions and attractions normally refer to a closed time interval with
regard to traffic (generally the average working day). The following model stages, EVA
Weighting and EVA Trip distribution and Mode choice, too, refer to the overall period. The
demand matrices available at the end of the model chain only can be combined with an
empirically determined or standardized daily time series (illustration 52) to get the shares of
demand for the individual times of the day. The daily time series depend on the demand
stratum.

PTV AG

135

Chapter 3: Demand model

Illustration 52: Daily time series for origin-destination groups of HW and WH (SrV 1987 Dresden)

The following table shows the allocation of activities, activity pairs, structural properties and
person groups on demand strata. Thereby the abbreviations used stand for the following: H:
Home; W: Work; C: Child care facility, S: School; F: Shift; P: Shopping; R: Recreation; O:
Others.
From/To

H
W

WH

CH

SH

FH

PH

RH

OH

HW

HC

HS

HF

HP

HR

HO
WO

OW

OO

Table 39: Typical break-down of a demand stratum into 8 activities and 17 demand strata = activity pairs
Demand stratum

136

Structural property (S) / Person group (P) of source zone i

HW

Employees

HC

Young children

HS

Pupils, apprentices, students

HF

Employees

HP

Inhabitants

HR

Inhabitants

HO

Inhabitants

WO

Jobs

PTV AG

Chapter 3.2: Demand modeling procedures

Demand stratum

Structural property (S) / Person group (P) of source zone i

WH

Jobs

CH

Jobs / capacity

SH

Jobs / capacity

FH

Jobs

PH

Jobs / sales floor

RH

Jobs / capacity

OH

Other jobs

OW

Other jobs

OO

Other jobs

DStr

Structural property (S) / Person group (P) of destination zone j

HW

Jobs

HC

Jobs / capacity

HS

Jobs / capacity

HF

Jobs

HP

Jobs / sales floor

HR

Jobs / capacity

HO

Other jobs

WO

Other jobs

WH

Employees

CH

Young children

SH

Pupils, apprentices, students

FH

Employees

PH

Inhabitants

RH

Inhabitants

OH

Inhabitants

OW

Jobs

OO

Other jobs

Table 40: Examples of relevant structural properties and person groups of the demand strata

Thus, for the demand strata HW and WH only the Employees person group (which could be
broken down into further subgroups) is relevant, whereas for the demand strata HO and OH
generally all person groups are relevant. The number of persons of all person groups in each
zone make up an important part of input attributes for the trip generation of a certain demand
stratum. Further structural properties measure the intensity of the activities at the origin or
destination. An example of the allocation of certain structural properties to individual demand
strata is illustrated by table 40.

PTV AG

137

Chapter 3: Demand model

The person groups specified here can be broken down into further subgroups according to
other features (car availability, age) and used for trip generation.
For each demand stratum and each relevant person group mobility rates have to be defined.
The mobility rate of a person group is defined as the average number of trips per day and
person.
MR pc =

Number of trips in DStr by persons of group p


.
Number of persons of person group p

In most cases, the MRpc values are known from national surveys on traffic behavior and are
assumed to be constant for all zones of the study area. If the individual zones feature different
specific traffic demands, for example distinguishing between urban and rural areas, they can
be used, too. Then MRepc specifies the particular demand of the person group or reference
person group p in zone e (in a certain demand stratum c).
Analogously production rates defined as the number of trips per day and structural property
are determined for the major structural properties like number of jobs, sales floor, etc.. To do
so empirical studies or available historical values can be referred to. Here, too, a differentiation
according to zones is possible. The structural potential of the zone results from the value of the
structural property and the related production rate.
A certain number of trips of the total production of a zone remains within the study area only,
the rest targets destinations outside. The same holds for destination traffic. Since the EVA
Model usually serves the calculation of study area-internal traffic (incoming and outgoing traffic
as well as through-traffic are often added by other sources), the share of trips of the total origin
(or destination) traffic made within the study area can be determined for all origin (or
destination) zones.
Example: The origin traffic of the demand stratum of Home-Work (HW) results from the number
of persons of the person group of Employees (EP) and the mobility rate MREP,HW. In a zone R
on the edge of a study area, however, part of the employees will commute to destination zones
outside the study area. It is not available for a later trip distribution and mode choice. In that
case, the study area factor UR,EP,HW is below 1, conveying that only that share of trips remains
within the study area. For a zone Z in the center, however, all trips of the demand stratum lie
within the study area. Therefore the following applies: UZ,EP,HW = 1. Study area factors do not
only depend on the zone but also on the demand stratum and the person group. It is more
probable that employees with car (E+c) commute over great distances and therefore to
destinations outside the study area than those without car (E-c). If you differentiate these two
person groups in the model, then would typically be UR,E-c,HW > UR,E+c,HW. And in analogy
hereto would be UR,Child,HC > UR,E+c,HW, because child care facilities are rather found in the
proximity of homes than jobs.
As the mobility rate of a person group the production rate of a structural property, too, can have
partial impacts in the study area only. So, for example, the structural potential of the demand
stratum HW is determined by the number of jobs (structural property J) and the related
production rate. On the edge of the study area part of the jobs are taken by employees living
outside the study area. Therefore, these jobs are not available as potential destinations of HW
trips of the study area. Therefore, in that case, too, the total structural potential is multiplied by
a study area factor VR,J,HWA < 1.

138

PTV AG

Chapter 3.2: Demand modeling procedures

You can limit calculation to the active zones. This allows you to e.g. exclude cordon zones from
the calculation.
In the trip generation stage (table 41, table 42 and table 43) from the structural data and values
mentioned for all demand strata c, the productions Qic and attractions Zjc or the upper limits

Qicmax and Zjcmax of these demands are calculated.


The approach depends on the origin-destination type of the activity pair of the demand stratum.
It specifies whether the activity pair affects the home activity of the road user as origin or
destination. Three types are possible.

Type 1: origin activity = home activity (own apartment, own work)


Type 2: destination activity = home activity (own apartment, own work)
Type 3: origin and destination activity home activity

The calculation specifications can be taken from table 41, table 42 and table 43. For the types
1 and 2 calculation starts with the home trips (of number of persons, mobility rate, study area
factor) which independently from the travel direction always occur in the origin zone. For type
1 the number of trips corresponds exactly to the production, for type 2 to the attraction of the
respective zone. For type 1 the total production (of all zones) is distributed onto the destination
zones, in proportion to their potentials (taken from structural properties, production rates and
study area factors). Type 2 is treated equally. The total attraction is distributed proportionally to
the potentials onto the origin zones. For type 3 total volume is equally calculated on the basis
of the total home trips. However, the sizes of the road users origin zones are relevant, which
do not have to correspond with origin or destination of the trip. Proportionally to the potential
the total volume is then distributed onto the origin zones on the one hand and onto the
destination zones on the other hand.
The productions and/or attractions so calculated can have various meanings.

Hard constraints

Traffic demand solely results from the spatial structure and has to be fully exhausted by the
trips calculated in the model.
Example: if the number of employed inhabitants and jobs per zone is known, hard
constraints will be applicable to the demand stratum Home Work (HW), since every
employed person necessarily has to commute to work and each job has to be destination
of commutation.

Weak constraints

Traffic demand does not only depend on the spatial structure but also on the convenience
of the location and the resulting competitive conditions. In these cases traffic demands
resulting from trip generation are like upper limits. With Trip distribution and Mode choice it
turns out to which extent the limits will be exhausted by the actually determined origin and/
or destination traffic.
The structural potential of the destination zone for the demand stratum Home Shopping
(HP) is usually calculated based on the structural property of sales floor and a production
rate for example. It is conceivable that there may be overabundance of sales floor so that
the shopping facilities are not used to their full potential. Therefore, the attraction calculated
by trip generation from the potential only constitutes an upper limit for real destination
traffic. Therefore, the constraint is hard on the destination side, whereas weak on the origin
side, because each road user has to shop (somewhere).

PTV AG

139

Chapter 3: Demand model

Elastic constraints

Elastic constraints are a generalization of weak constraints. Additionally to upper limits


lower limits are equally known, for the demand stratum Home - Shopping (HP), for
example, from sales statistics. In this case, the structural potential of the sales floor
determines an interval for the attraction of the respective zone.

Open constraints

The potential of the structural properties merely represents the attractiveness of the zone
as an origin or destination of a demand stratum. Production or attraction, however, are not
linked to any constraint.
The attractiveness of some destinations in recreational traffic can even be measured by
means of their attributes if capacity impacts do not play a role. For example, the structural
potential of a nearby recreational area can be determined by its forest. During trip
distribution this attractiveness is to impact as potential of the destination zone, but no
constraints are linked herewith because there is neither a minimum number of persons
seeking recreation nor do visitors go to other places, because the "capacity" of the forest is
fully exhausted.
In table 41, table 42 and table 43 the calculation formulas are listed up separately for the cases
for which they differ.
Step 1

Home trips H

H epc = MR epc BP ep u epc


H ec = MR epc BP ep u epc
pP

Step 2

Production Q, Qmax

Q ic = H ic
Step 3

Total volume V

Vc =
fc =

Q ic

i =1

Vc

ERsc SGs vsc


=1 sS
Table 41: Trip generation in EVA model: OD type 1

140

PTV AG

Chapter 3.2: Demand modeling procedures

Step 4

Attraction Z, Zmax

ER jsc SG js v jsc
sS
max
b ) Z jc Z max
jc = ER jsc SG js v jsc
sS
jc = ER max
jc Z jc Z jc Z jc
c )Z
jsc SG js v jsc ; Z jc Z
sS
d ) Z pot
jc = ER jsc SG js v jsc
sS
a ) Z jc = f c

Table 41: Trip generation in EVA model: OD type 1

Step 1

Home trips H

H epc = MR epc BP ep u epc


H ec = MR epc BP ep u epc
pP

Step 2

Attraction Z, Zmax

Z jc = H jc
Step 3

Total volume V

Vc =
fc =

Z jc

j =1

Vc

ERsc SGs vsc


=1 sS
Step 4

Production Q, Qmax

ERisc SGis visc


sS
max
max SG v
b )Q Q
= ERisc
is isc
ic
ic
sS
max SG v ; Q
= ERisc

c )Q
is isc ic Qic Qic Qic Q
ic
ic
sS
pot
d )Q
= ERisc SGis visc
ic
sS
a ) Q = fc
ic

Table 42: Trip generation in EVA model: OD type 2

PTV AG

141

Chapter 3: Demand model

Step 1

Home trips H

H epc = MR epc BP ep u epc


H ec = MR epc BP ep u epc
pP

Step 2

Total volume V

Vc =
Step 3

H ec

e =1

Production Q, Qmax

ERisc SGis visc


sS
Qic =
Vc
ERsc SGs vsc
sS
Attraction Z, Zmax

ER jsc SG js v jsc

Z jc =

sS

ERsc SGs vsc

Vc

sS

Table 43: Trip generation in EVA model: OD type 3

142

e
i
j
s
p
c
m
MRepc

Index of a zone producing trips (origin zone)

ERisc

Production rate of structural property s per time interval

BPep

Number of persons per person group p

SG
uepc

Structural property

visc

Structural property factor effective for study area-internal traffic

Hepc

Home trips (expected value) of person group p

Hec

Home trips (expected value) total

Qic

Production (expected value)

Zjc

Attraction (expected value)

Index of a zone being origin of trips


Index of a zone being destination of trips
Index of a structural property
Index of a person group
Index of a demand stratum
Number of zones in study area
Mobility rate of person group p per time interval

Factor of trips realized study area-internally

PTV AG

Chapter 3.2: Demand modeling procedures

Qicmax

Maximum possible production

Zjcmax

Maximum possible attraction


Factor for upper or lower limit of production

Q ,Qic
ic

Factor for upper or lower limit of attraction

Z jc , Z jc

Qicpot

Potential for origin traffic

Zjcpot

Potential for destination traffic

Vc

Total volume (expected value)

fc

Factor, which takes the compliance of the total constraint

V =

Qi
i

Zj
j

for the

calculation of the zones traffic volume into consideration

Qic*,

Zjc

Ancillary parameters for balancing (see below)

When analyzing the passenger demand flows it turns out that certain activity chains dominate
in the course of a day. So, for example, the chain of H W - P H occurs more often than the
chain of H P W H. With this, imbalances in the respective demand stratum pairs arise (for
example HW compared to WH) that are expressed in mobility or production rates.
Consequently, when calculating the total production of a certain zone i across all demand
strata, this sum does generally not correspond to the total attraction. This, however, should be
the case for a period considered closed with regard to traffic. Hence, in the EVA model, the
production or attraction of a selected ca demand stratum of the type 3 (mostly Others Others,
OO) is modified, so that the total production equals the total attraction across all demand
strata. This procedure is called balancing (see "EVA trip distribution and mode choice" on
page 152).
Balancing can either be performed after trip generation or trip distribution and mode choice. It
takes place after trip generation if the following conditions are fulfilled.

All constraints (except those of demand stratum ca) are hard.

The total volume in ca is higher than the difference between production and attraction that
needs to be balanced.
All modes are interchangeable.

Balancing after trip generation takes place in three steps.


1. Calculation of total production and total attraction for all demand strata except ca.

Q*i =

Qic Z *i = Z ic
c ca ;
c ca

2. Calculation of the demand to be compensated of all zones i.

Q*i = max{ 0 , Z *i Q*i } ; Z *i = max{ 0 , Q*i Z *i }

PTV AG

143

Chapter 3: Demand model

~
~
3. Correction of traffic volume in ca, whereby Qica and Zica are "preliminary" values taken
from the formulas in table 41, table 42 and table 43.
*
*
1
1 ------Q ic = Q

Q l + Z i
ic a
V c l

a
a

1
*
*
Z ic = Z ica 1 ------- Z l + Q i
Vc

a
l
a

If there are non-interchangeable modes, you need to perform the balancing procedure for each
of them individually. Then you perform a single balancing procedure for the sum of all
interchangeable modes. This, however, is only possible during distribution and mode choice.
The following example will illustrate the method. For simplification it is limited to five demand
strata covering all origin-destination types.
Activity
No.

Code

OD type

Person group

Origin

Destination

Origin zone

HW

Home

Work

Employees

HO

Home

Others

Inhabitants

WH

Work

Home

Employees

OH

Others

Home

Inhabitants

OO

Others

Others

Inhabitants

Relevant structural potential


No.

Origin zone

Destination zone

Code
HW

OD type
1

Like home

Jobs

HO

Like home

Jobs in tertiary sector and


inhabitants

WH

Jobs

Like home

OH

Jobs in tertiary sector and


inhabitants

Like home

OO

Jobs in tertiary sector and


inhabitants

Jobs in tertiary sector and


inhabitants

The model covers 18 zones, 10 of which belong to the actual study area (type 1) and 8 zones
form a cordon around them (type 2). The zones of type 1 feature study area factors of 1.0,
those of type 2 of 0.9. The relevant zone attributes are set as follows.
Zone

144

Type

Inhabitants

Employees

Jobs

Jobs tertiary

7,000

3,000

2,000

1,100

10,500

5,500

7,000

4,500

7,000

3,000

2,000

1,300

5,000

2,000

1,700

1,000

PTV AG

Chapter 3.2: Demand modeling procedures

Zone

Type

Inhabitants

3,000

Employees

Jobs

2,000

900

1,600

1,000

500

200

2,000

1,200

1,200

Jobs tertiary
2,500

1,600

5,000

2,000

1,000

600

7,000

3,100

2,500

1,400

10

5,000

2,000

1,500

1,000

11

3,500

1,200

1,000

600

12

3,000

1,100

1,000

600

13

2,500

1,000

1,000

600

14

1,500

700

500

100

15

1,500

600

500

100

16

2,000

900

1,000

600

17

2,000

800

500

300

18

2,000

800

500

300

Depending on demand stratum and zone type the following mobility rates are applicable (trips
per person in relevant person group).
Zone type

HW

HO

WH

OH

OO

0.7800

0.9000

0.6200

0.9000

0.6000

0.8100

0.9000

0.6400

0.9000

0.6000

The production rates of the structural properties equally depend on demand stratum and zone
type.
Demand stratum

Structural property

HW
HO

OO

PTV AG

Zone type 2

1.00

1.00

Inhabitants

0.50

0.50

Jobs in tertiary sector

0.50

0.50

WH
OH

Zone type 1

1.00

1.00

Inhabitants

0.50

0.50

Jobs in tertiary sector

0.50

0.50

Inhabitants

0.50

0.50

Jobs in tertiary sector

0.50

0.50

145

Chapter 3: Demand model

All demand strata feature hard constraints. This results in the productions and attractions of the
demand strata displayed in the following table, from the formulas in table 41, table 42 and
table 43. For clarification the respective step of the calculation process is indicated on top of
each column.

H = Home trips
Q = Production
Z = Attraction
QP = Structural potential origin
ZP = Structural potential destination

Demand stratum

HW

Person groups or structural


property
Calculation step

Origin
Like home

Jobs

Destination

Zone

Zone Type

ZP

2,340

2,340

2,000

1,578

4,290

4,290

7,000

5,523

2,340

2,340

2,000

1,578

1,560

1,560

1,700

1,341

936

936

2,500

1,972

702

702

1,600

1,262

156

156

2,000

1,578

1,560

1,560

1,000

789

2,418

2,418

2,500

1,972

10

1,560

1,560

1,500

1,183

11

875

875

900

710

12

802

802

900

710

13

729

729

900

710

14

510

510

450

355

15

437

437

450

355

16

656

656

900

710

17

583

583

450

355

18

Total

146

Home
Employee
s

583

583

450

355

23,038

23,038

29,200

23,038

PTV AG

Chapter 3.2: Demand modeling procedures

Demand stratum

HO

Person groups or
structural property
Calculation step

Home

Origin

Inhab.

Like
home

Destinati
on
Jobs in tertiary sector and inhabitants

3.1

3.2

Zone

Zone Type

ZP Inh.

ZP Jobs
tert

ZP Total

6,300

6,300

3,500

550

4,050

5,796

9,450

9,450

5,250

2,250

7,500

10,733

6,300

6,300

3,500

650

4,150

5,939

4,500

4,500

2,500

500

3,000

4,293

2,700

2,700

1,500

800

2,300

3,292

1,800

1,800

1,000

500

1,500

2,147

450

450

250

600

850

1,216

4,500

4,500

2,500

300

2,800

4,007

6,300

6,300

3,500

700

4,200

6,011

10

4,500

4,500

2,500

500

3,000

4,293

11

2,835

2,835

1,575

270

1,845

2,640

12

2,430

2,430

1,350

270

1,620

2,318

13

2,025

2,025

1,125

270

1,395

1,996

14

1,215

1,251

675

45

720

1,030

15

1,215

1,251

675

45

720

1,030

16

1,620

1,620

900

270

1,170

1,674

17

1,620

1,620

900

135

1,035

1,481

18

Total

1,620

1,620

900

135

1,035

1,481

61,380

61,380

34,100

8,790

42,890

61,380

Demand stratum

WH
Home

Person groups or structural


property
Calculation step

PTV AG

Destination

Origin

Like home

Jobs

Zone

Zone Type

QP

1,860

1,860

2,000

1,253

3,410

3,410

7,000

4,384

1,860

1,860

2,000

1,253

1,240

1,240

1,700

1,065

147

Chapter 3: Demand model

744

744

2,500

1,566

558

558

1,600

1,002

124

124

2,000

1,253

1240

1,240

1,000

626

1,922

1,922

2,500

1,566

10

1,240

1,240

1,500

939

11

691

691

900

564

12

634

634

900

564

13

576

576

900

564

14

403

403

450

282

15

346

346

450

282

16

518

518

900

564

17

461

461

450

282

18

461

461

450

282

18,288

18,288

29,200

18,288

Total

Demand stratum

OH

Person groups or
structural property
Calculation step

148

Home

Destinati
on

Origin

Inhab.

Like
home

3.1

3.2

QP Inh.

QP Jobs
tert

QP Total

Jobs in tertiary sector and inhabitants

Zone

Zone Type

6,300

6,300

3,500

550

4,050

5,796

9,450

9,450

5,250

2,250

7,500

10,733

6,300

6,300

3,500

650

4,150

5,939

4,500

4,500

2,500

500

3,000

4,293

2,700

2,700

1,500

800

2,300

3,292

1,800

1,800

1,000

500

1,500

2,147

450

450

250

600

850

1,216

4,500

4,500

2,500

300

2,800

4,007

6,300

6,300

3,500

700

4,200

6,011

10

4,500

4,500

2,500

500

3,000

4,293

11

2,835

2,835

1,575

270

1,845

2,640

12

2,430

2,430

1,350

270

1,620

2,318

13

2,025

2,025

1,125

270

1,395

1,996

14

1,215

1,215

675

45

720

1,030

PTV AG

Chapter 3.2: Demand modeling procedures

15

1,215

1,215

675

45

720

1,030

16

1,620

1,620

900

270

1,170

1,674

17

1,620

1,620

900

135

1,035

1,481

18

1,620

1,620

900

135

1,035

1,481

61,380

61,380

34,100

8,790

42,890

61,380

Total

Demand stratum

OO
Home

Origin

Person groups or structural


property

Jobs in tertiary sector and inhabitants

Calculation step

2.1

2.2

2.3

Zone

Zone Type

QP Inh.

QP Jobs
tert

QP Total

4,200

3,500

550

4,050

3,864

6,300

5,250

2,250

7,500

7,156

4,200

3,500

650

4,150

3,959

3,000

2,500

500

3,000

2,862

1,800

1,500

800

2,300

2,194

1,200

1,000

500

1,500

1,431

300

250

600

850

811

3,000

2,500

300

2,800

2,671

4,200

3,500

700

4,200

4,007

10

3,000

2,500

500

3,000

2,862

11

1,890

1,575

270

1,845

1,760

12

1,620

1,350

270

1,620

1,546

13

1,350

1,125

270

1,395

1,331

14

810

675

45

720

687

15

810

675

45

720

687

16

1,080

900

270

1,170

1,116

17

1,080

900

135

1,035

987

18

Total

1,080

900

135

1,035

987

40,920

34,100

8,790

42,890

40,920

Demand stratum

OO
Destination

Person groups or structural


property
Calculation step

PTV AG

Jobs in tertiary sector and inhabitants


3.1

3.2

3.3

149

Chapter 3: Demand model

Zone

Zone Type

ZP Inh.

ZP Jobs tert

ZP Total

3,500

550

4,050

3,864

5,250

2,250

7,500

7,156

3,500

650

4,150

3,959

2,500

500

3,000

2,862

1,500

800

2,300

2,194

1,000

500

1,500

1,431

250

600

850

811

2,500

300

2,800

2,671

3,500

700

4,200

4,007

10

2,500

500

3,000

2,862

11

1,575

270

1,845

1,760

12

1,350

270

1,620

1,546

13

1,125

270

1,395

1,331

14

675

45

720

687

15

675

45

720

687

16

900

270

1,170

1,116

17

900

135

1,035

987

18

Total

900

135

1,035

987

34,100

8,790

42,890

40,920

Since all demand strata feature hard constraints, balancing can be performed immediately
after trip generation. First of all the total origin and destination traffic of each zone and of the
demand strata HW, HO, WH, OW is calculated and the resulting differences are compensated
in the OO demand stratum.
Note: Note that neither total origin and nor total destination traffic of this demand stratum
change.
Total HW+HO+WH+OH

150

Differences

Zone

16,800

14,422

2,378

26,600

31,373

4,773

16,800

14,709

2,091

11,800

10,993

807

7,080

10,121

3,041

4,860

6,558

1,698

1,180

5,263

4,083

11,800

9,429

2,371

PTV AG

Chapter 3.2: Demand modeling procedures

16,940

15,559

1,381

10

11,800

10,710

1,090

11

7,236

6,555

681

12

6,296

5,911

385

13

5,355

5,267

88

14

3,344

2,698

646

15

3,213

2,698

515

16

4,415

4,623

208

17

4,284

3,599

685

18

4,284

3,599

685

Total

164,086

164,086

13,804

13,804

OO before balancing
Zone

OO after balancing
Z

3,864

3,864

2,561

4,938

7,156

7,156

9,515

4,742

3,959

3,959

2,624

4,715

2,862

2,862

1,897

2,704

2,194

2,194

4,495

1,454

1,431

1,431

2,646

948

811

811

4,621

537

2,671

2,671

1,770

4,141

4,007

4,007

2,655

4,036

10

2,862

2,862

1,897

2,987

11

1,760

1,760

1,166

1,848

12

1,546

1,546

1,024

1,409

13

1,331

1,331

882

970

14

687

687

455

1,101

15

687

687

455

971

16

1116

1116

948

740

17

987

987

654

1,339

18

987

987

654

1,339

Total

40,920

40,920

4,0920

40,920

The results of operation EVA trip generation are stored in zone attributes.

PTV AG

Attribute

Subattribute

Meaning and range of values

HomeTrips

Demand stratum

Home trips for demand stratum


Range: floating point number

151

Chapter 3: Demand model

Attribute

Subattribute

Meaning and range of values

ProductionsTarget

Demand stratum

Productions for demand stratum, before taking account of


constraints
Range: floating point number

AttractionsTarget

Demand stratum

Same for attractions


Range: floating point number

Productions

Demand stratum

Productions for demand stratum after taking account of


constraints and balancing
Note
This attribute is only available after EVA trip generation if all
demand strata feature hard constraints, otherwise after
EVA trip distribution / mode choice only.
Range: floating point number

Attractions

Demand stratum

Same for attractions


Range: floating point number

3.2.2.3

EVA trip distribution and mode choice

In gravity models, trip distribution or destination choice is made according to the bilinear
approach (for example Kirchhoff 1970), using various evaluation or utility functions Wij.
Tij = Wij fq i fz j

Wij fqi fz j

( i = 1,..., m; j = 1,..., n)

Tij = Qi

j =1
j =1
m
m
Wij fqi fz j = Tij = Z j
i= 1
i =1
Hereby Tij is the number of trips from i to j, Wij is the cost function for the trip from i to j, Qi is
the production of zone i and Zj is the attraction of zone j. The factors fqi, fzj are calculated so
that productions and attractions are kept as marginal sums.
The EVA model generalizes this approach of a simultaneous trip distribution and mode choice
to a trilinear model.
Tijk = Wijk fqi fz j fa k

Wijk

fqi fz j fa k =

( i = 1,..., m; j = 1,..., n; k = 1,..., p)

Tijk = Qi

j =1 k = 1
j =1 k =1
m p
m p
Wijk fqi fz j fa k = Tijk = Z j
i= 1 k = 1
i =1 k =1
m n
m n
Wijk fqi fz j fa k = Tijk = VK k
i= 1 j = 1
i =1 j =1

152

PTV AG

Chapter 3.2: Demand modeling procedures

Here, index k is the mode (means of transport) and Wijk assesses the costs for the trip from i to
j by modes k. For each demand stratum c there is a separate equation system to be solved
independently. For more clarity index c has been dropped for all variables in the problem
formulations above.
For the trilinear case, besides origin and destination traffic, the total number VKk of trips with
mode k is required. There are two possibilities.

If EVA trip distribution and mode choice for the analysis case is performed, which means
without having run a pre-calculation for the same study area, specify the modal split as
input data.
If, however, a forecast case is calculated, the modal split of the analysis case can be reused. You thus assume that the modal split may change on single relations, but modal split
of the whole model (including all relations), however, remains unchanged.

The problem formulation is applicable in case of hard constraints. For weak, elastic or open
constraints equations will be replaced by inequations in the side conditions or a side condition
will be dropped completely. This will be dealt with when describing the problem solutions.
The models can be justified by the probability theory using Bayes axiom or the information
gain minimization. Both ways lead to the same result.
Minimizing the gain of information has the target that the deviations from a priori assessments
of trip relations which would lead to the actually desired trips road users have to experience are
as minor as possible, but which have become necessary due to the constraints of the system.
The demand matrix T can be interpreted as the solution to the convex optimization task

pijk
Minimum
I = pijk ld
wijk

ijk
Tijk
;
V

Wijk
Wrsl
rsl
taking account of the constraints. The solution is the trilinear equation system previously
determined.

with pijk =

wijk =

The parameter I represents the information gained through the replacement of distribution wijk
(solely determined by the weighting matrix) by distribution pijk (additionally derived from
marginal totals).

Weighting probabilities (impedance functions)


In general, the total trips costs include various factors (e.g. journey time, egress/access time,
monetary costs, number of passenger transfers etc.). In the EVA model, these are called
assessment types. In the EVA model the different assessments of each assessment type are
transformed separately by a utility function and then multiplied.
If caijk is the assessment of type a of a trip from i to j by mode k, then the following applies:

W ijk = M ijk C ijk P ijk


whereby

PTV AG

153

Chapter 3: Demand model

P ijk = [ f a' ( c a'ijk ) f a'' ( c a''ijk ) ] f a''' ( c a'''ijk )

aA

f a ( c aijk )

Here Mijk stands for the availability of mode k on OD pairs (i,j) and Cijk stands for the capacity
utilization of mode k on (i,j). a, a and a are the predefined assessment types: journey time,
competing walk time and external weighting matrix. A is the number of user-defined
assessment types.

Mijk and Cijk are defined independently from the demand stratum as follows:
OD type

Definition of Mijk and Cijk

Type 1

Mijk = mk(i) for all j, i.e. value of zone attribute mk set for source zone i
Cijk = ck(j) for all i, i.e. value of zone attribute ck set for destination zone j

Type 2

Mijk = mk(j) for all i, i.e. value of zone attribute mk set for destination zone j
Cijk = ck(i) for all j, i.e. value of zone attribute ck set for source zone i

Type 3

without accounting for home zone


Mijk = 1 for all i,j,k
Cijk = ck(i) ck(j)
including accounting for home zone

n mk ( n ) hn P nik P jnk

M ijk = --------------------------------------------------------------- hn
n

Cijk = ck(i) ck(j)

represents the product matrix from the


whereby hn stands for the home trips of zone n, P
top, but the predefined assessment type External weighting matrix is not included in the
product:

P ijk = [ f a' ( c a'ijk ) f a'' ( c a''ijk ) ]

aA

f a ( c aijk )

For demand strata of the origin-destination type 3 (which are calculated accounting for the
home zone), the assessment type External weighting matrix is used to produce a specific
weighting between zones and modes. This weighting has an immediate impact on the total
product, since it is not part of the scaling using home zones, as in the formula for Mijk. In all
other cases, this assessment type has the same effect as a user-defined one.
You can use different function types as fa evaluation functions. All distribution functions of the
gravity model (cf. chap. 5.1.4.17) can be taken, but additionally the EVA1, EVA2, Schiller and
Box-Tukey functions (see "Gravity model calculation" on page 174), too.
EVA1

EVA2

154

a
f (x ) = ( 1 + x ) ( x ) whereby ( x ) = 1 + exp( b cx )
b

x
f (x ) = 1 +
c

PTV AG

Chapter 3.2: Demand modeling procedures

Schiller

f (x ) =

1
x
1+
b

Logit

f (x ) = e (c x )

Kirchhoff

f (x ) = x c

Box-Cox

xb 1
c

f ( x ) = e

Box-Tukey

( x + 1 )b 1 / b ,
) whereby
(
c

x
=

f (x ) = e

Combined

f (x ) = a x b e (c x )

TModel

f (x ) =

None

ln( x + 1 ),

b >0
b =0

1
b
x + c xa

f(x) = x

In practice particularly the functions EVA1 and EVA2 have proved to be suitable. The EVA1
functions are monotonously falling with f(w) 1 for w 0. In illustration 53 some of them have
been illustrated. Their parameters can be interpreted geometrically.

Parameter marking the horizontal asymptote of function (w), thus influencing the degree of
approximation of the function f(w) to the w asymptote.

Parameter influencing the degree of approximation to the horizontal F(w)=1 in the proximity
of low assessment

c
b/c

Parameter influencing the slope of the function f(w)


Position of the inflection point WP=F/G of function (w) where the function (w) features the
greatest rise or the highest "impedance sensitivity"

The related elasticity functions are determined by

f ( w )=

1
G exp( F G w )
Ew

+ ln( 1 + w )
.
1 + exp( F G w )
1 + exp( F G w ) 1 + w

f ( w + h ) f ( w ) h df ( w )
w
=

is defined as the
f (w)
w
dw
f (w)
limit of the quotient of the relative variation of the function f and the relative variation of the
impedance w.

The elasticity function f ( w )= limh 0

It is obvious that the elasticity functions first take values near zero for low impedances, then for
a limited range in which the impedance sensitivity is at its highest take various values, but all
far from zero and for high impedances approximate the limit of -E.

PTV AG

155

Chapter 3: Demand model

Thus, this curve very much differs from the constant or linear elasticity functions of simple
power and exponential functions. Therefore, this type of function allows the adaptation to
various basic weighting situations (person groups, trip purposes, means of transport etc.). In
the range of low assessment or utility the weighting probability should be almost one, drop
further in the clearly noticeable range of assessment and utility which is relevant for the
respective type of traffic or purpose before asymptotically approximating zero. For example,
the assessment in the proximity of or in smaller towns plays a minor or no role at all for the road
users when choosing the destination or the means of transport (here mainly the random model
with WP = 1 is applicable).

f1(E=2; F=5; G=0,24)


f3(E=0,6; F=6; G=0,06)

f2(E=4; F=6; G=0,08)


f4(E=20; F=12;G=0,08)

1,1
1
0,9
0,8
0,7
f(w) 0,6
0,5
0,4
0,3
0,2
0,1
0
0 10 20 30 40 50 60 70 80 90 100 110120

0 10 20 30 40 50 60 70 80 90 100110 120
0
-5
-10
eps(w) -15
-20
-25
-30
Illustration 53: EVA1 function in dependence of impedance w

The EVA2 function has the following parameters.


a, b ...

156

Exponents whose product determines the asymptotic behavior for high impedance values.
For b > 1 the curve is similar to that of the EVA function (1).

PTV AG

Chapter 3.2: Demand modeling procedures

c ...

Scale parameter for impedance values.

f ( c ) = 1 / 2 applies.

The illustration 54 shows the influence of a and b on the progression of the function. The two
other parameters are both kept constant.
EVA2 Function (a variable)
1,0
0,9

Utility f(x)

0,8
0,7

a=0

0,6

a=1
a=2

0,5

a=3

0,4
0,3
0,2
0,1
100

95

90

85

80

75

70

65

60

55

50

45

40

35

30

25

20

15

10

0,0
Assessment x

EVA2 Function (b variable)


1,0
0,9
0,8

Utility f(x)

0,7
b=1

0,6

b=3

0,5

b=5

0,4

b=7

0,3
0,2
0,1

Assessment x

100

95

90

85

80

75

70

65

60

55

50

45

40

35

30

25

20

15

10

0,0

Illustration 54: EVA2 function in dependence of the parameters a and b

The Schiller function is a special case of the EVA2 function, however, with one parameter less.
As the first applications in practice have shown, the function can also be adapted sufficiently
well enough to observed data. Due to the lower number of parameters the calibration effort is
by far lower than for EVA2.

PTV AG

157

Chapter 3: Demand model

Problem solution 1: The trilinear FURNESS method


The mostly investigated method for solving bilinear problems in technical literature is named
after K. P. Furness (Furness 1962, 1965). However, in fact, Bregman had already applied this
method in the thirties (Bregman 1967a, 1967b). It can be generalized and transferred directly
to the trilinear case.
After you have specified start values for the trilinear FURNESS method

fqi (1) = fz j (1) = fak (1) = 1

(i = 1,..., m; j = 1,..., n; k = 1,..., K )

during iteration step p (p=1,2,), the system calculates approximations for fqi, fzj and fak as
follows.

fqi ( p + 1) =
n

Qi
K

Wijk fz j ( p ) fak ( p ) (i = 1,,m)


j =1 k =1
Zj

fz j ( p + 1) =

m K

Wijk fqi ( p + 1) fak ( p )

(j = 1,,n)

i =1k =1

VK k

fak ( p + 1) =

m n

Wijk fqi ( p + 1) fz j ( p + 1)

(k = 1,,K).

i =1 j =1

For convergence of the method (towards the solution of the trilinear problem), the condition for
unique solvability of the optimization problem is necessary and sufficient, i.e. existence of a
matrix Tijk that matches the constraints and for which Tijk = 0 is true for all pairs (i,j) with Wij =
0. This condition is fulfilled when Wij > 0 is true for all (i,j), since then the matrix with elements

Qi Z j fak
(the matrix that corresponds to the random model) can be chosen as a
V
feasible solution. For this special case A. W. Evans provided a convergence proof that also
allows for a (however rough) estimation of the convergence rate (Evans 1970). The practical
experience has shown that the method quickly converges in most application cases.
Tijk =

Problem solution 2: The trilinear Multi method


Another possibility to solve the problem is to set separate fixed point equations for the vectors
fqi, fzj and fak and use them to derive rules for determining successive approximations for these
vectors (Schnabel 1997). The Multi-Procedure can also be extended to the three dimensional
case (see "Projection" on page 188). Approximations for the solution of the trilinear problem
then can be determined according to the following iteration rule.

Tijk (1) = Wijk

158

(i = 1,...,m;

j = 1,...,n; k = 1,..., K )

PTV AG

Chapter 3.2: Demand modeling procedures

q ( p ) z j ( p ) ak ( p )
V
Tijk ( p + 1) = Tijk ( p ) i

qqi ( p ) zz j ( p ) aak ( p ) m n K

Trst ( p )
r =1 s =1t =1

(p = 1, 2,)
with

Qi
qi ( p ) =
n K
Tist ( p )
s =1t =1
n K

Tist ( p ) [zs ( p ) + at ( p )]

qqi ( p ) = s =1t =1
n K
2 Tist ( p )
s =1t =1

z j ( p) =

Zj
m K
Trjt ( p )
r =1t =1

m K

Trjt ( p ) [qr ( p ) + at ( p )]

zz j ( p ) = r =1t =1

m K

Trjt ( p )

r =1t =1

VK k
ak ( p ) =
m n
Trsk ( p )
r =1 s =1
m n

Trsk ( p ) [qr ( p ) + zs ( p )]

aak ( p ) = r =1 s =1

m n

Trsk ( p )

r =1 s =1

Strictly speaking the method presented solves the problem with hard constraints only. If some
constraints are weak or elastic, there will be an optimization problem with inequations as side
conditions instead of equations. At the example of weak constraints it is illustrated how the
problem and correspondingly its solution alters (according to Schiller 2004). It is assumed that
a demand stratum shows weak constraints on the destination side, which means attraction
calculated by trip generation constitutes an upper limit. Thus, the trilinear problem changes into

Tijk = Wijk fqi fz j fak

PTV AG

159

Chapter 3: Demand model

under the constraints

Tijk

= Qi

j k

Tijk
i k

Tijk

Z max
j
= VK k

i j
The procedure for multi-problem solving is mostly identical with the constraint equation
method, except that zj(p) and zzj(p) are calculated differently.

Z max
1
j

z j ( p ) = min
;
; fz j (0 ) = 1
fz
p
1
Z
p
(
)
(
)

ijk ( p ) (qi ( p ) + ak ( p ))

1
zz j ( p ) = min
; i k

fz
p
1
2
Z
p
(
)
(
)
j
j

If some demand strata do not feature hard constraints, not only has the method to be adapted
but also balancing has to be made up.
Note: Differences in marginal sums can only be balanced after trip generation if all demand
strata feature hard constraints.
In that case first of all the trilinear problem is solved for all demand strata except for the
balancing one. This results in the total productions and attractions of the zones covering these
demand strata and all modes. According to the formula for calculating productions and
attractions (see "EVA trip generation" on page 135), the productions and attractions of the
balancing demand stratum are modified. Finally Visum runs trip distribution and mode choice
for this last demand stratum, too.
The proceeding assumes that differences have to be balanced within the framework of the total
volume. This is only true if all modes are exchangeable, which means if they can be used
alternatively in a closed trip chain. If at least one mode cannot be exchanged, a second phase
begins after the total balancing in which calculations are performed for each non-exchangeable
mode separately and for all exchangeable modes jointly. Hereby, the productions and
attractions of the respective modes are calculated over the non-balancing demand strata,
their differences are compensated by an adaptation of the demand of the balancing demand
stratum, and based on that modified demand Trip distribution and Mode choice are calculated
for the last time. For non-exchangeable modes this last step corresponds to a simple mode
choice.
The implementation of the EVA model for trip distribution and mode choice has been
established in two separate operations. EVA Weighting uses skim matrices to calculate the
weighting matrices Wijk (one weighting matrix each per demand stratum). During EVA trip
distribution and Mode choice, the equation systems for determining the demand matrices are
set up according to the constraints of the demand strata and solved by applying one of the
above-described methods. The result of the operation is one demand matrix per demand

160

PTV AG

Chapter 3.2: Demand modeling procedures

stratum and mode. You can also display the balance factors for productions and attractions fqi
and fzj, that result from the equation system. The balance factor for mode choice fak is
calculated for analysis, but not for forecast scenarios.
The EVA weighting procedure can be applied to all active OD pairs or only to those OD pairs
whose origin or destination zone are active. This allows you to perform an analysis based on
filtering by several OD pairs with different parameters. This option is not available for combined
distribution and mode choice, as for successful balancing, all traffic types need to be
accounted for in one step.

3.2.3

Activity chain based model (tour-based model)


The tour-based model is a disaggregated, behavior-oriented demand model which allows the
planner to include all kinds of data relating to socio-demography and traffic policy issues. The
tour-based model calculates three logical work units.
1. Trip generation (calculating the home trip)
2. Trip distribution (determining the trip destination)
3. Mode choice
These three logical units are not processed separately in succession by the tour-based model,
but are interlocked. Especially steps 2 and 3, Trip distribution and Mode choice are carried out
simultaneous in a single procedure. In all three work units two important concepts have been
implemented for the tour-based model: Calculation on the basis of groups with homogeneous
behavior and activity chains.

3.2.3.1

Tour-based data model

The tour-based model is based on the assumption that external activities cause mobility. In the
following examples previously defined activities are already being used (see "Activities, activity
pairs, activity chains" on page 122).
An activity chain describes a sequence of typical activities during a person's day. An example
would be: Home Work Shopping Home (HWOH). Such a sequence of activity pairs
implies trips, in this example here three different trips: HW, WO, OH. The average mobility
program of persons is described by activity chains for the tour-based model.
You can find the demand object activity chain attributes in the general description of the
demand objects (see "Activities, activity pairs, activity chains" on page 122).
Some changes in the demand objects, which are especially necessary for the tour-based
model, are described below.
Note: In a Visum-tour-based demand model, a demand stratum is specified by exactly one
person group (e.g. E+c) and one activity chain (e.g. HWOH). In the other demand models,
several person groups can be assigned to one demand stratum.

Changes to activities in the tour-based model


Each activity from the activity chain, apart from the home activity, has to be assigned to exactly
one structural property, whose value flows in as target potential into the trip distribution.
The following table shows examples for activities and respective structural properties.

PTV AG

161

Chapter 3: Demand model

Activity

Structural property

Structural property value = target potential


Number of jobs

Work ('W')

Jobs

Shopping ('O')

Shopping possibilities Retail sales floor

Recreation ('R')

Recreational facilities

Number of mentions of the zone as recreation destination


in a household survey

School ('S')

School places

Number of school places (up to 18 years)

University ('U')

University places

Number of university places

You can specify whether a possible destination-binding can be considered for trip distribution,
per activity. If desired, a constraint for the destination side (for example hard, weak, elastic,
open) can be defined analog to the EVA demand model using two real-valued factors
ConstraintMinFactorDest and ConstraintMaxFactorDest. Depending on the constraint on
origin and destination side, the doubly-constrained trip distribution is calculated for each
activity transfer.
This results in the following new attributes:
Type of demand Attribute and range of values
object

Meaning

Activity

StructuralPropertiesCodes
Range: set of structural properties

Reference to the activity relevant structural


properties

Activity

ConstraintDest
Range: bool {0, 1}

Destination-sided coupling during trip distribution


(yes / no). Home activity always =1.

Activity

ConstraintMinFactorDest /
ConstraintMaxFactorDest
Range: floating point number 0

Factor for the lower or upper limit of the


constraint on destination side, if ConstraintDest =
1.
For home activity, both factors are always = 1.0.

Changes to activity pairs in the tour-based model


The tour-based model offers a hourly calculation of the demand. This calculation requires as
input, proportional time series which are defined separately per activity pair and person group.
This results in the following new attribute:

162

Type of demand
object

Attribute and range of values

Subattribute

Meaning

Activity pairs

TimeSeriesNo
Range: set of standard time
series (see "Time series" on
page 121)

Person group

Reference to a standard
time series, which has to be
proportional

PTV AG

Chapter 3.2: Demand modeling procedures

3.2.3.2

Tour-based model trip generation

Trip generation uses a list of group-specific activity chains, which for example, can be
determined from the sample of the KONTIV 89 (EMNID 1991) by applying a PTV company
optimization procedure for activity chains. For each activity chain probabilities of your daily
practice have to be specified for each person group. The following table (to calculate the
probabilities, these values must be divided by 100) contains examples of activity chain
percentages for each person group.
E+c

E-c

NE+c

NE-c

Appren

Stud

SPup

PPup

Child

HWH

74.25

62.60

8.18

2.82

33.48

11.08

1.92

0.30

0.00

HSH

0.00

0.00

0.00

0.00

47.57

0.00

0.00

0.00

0.00

HPH

17.42

25.94

60.60

62.93

12.37

23.91

12.99

9.08

0.00

HRH

27.03

25.32

52.50

39.74

38.08

37.33

40.12

38.67

0.00

HPH

0.00

0.00

0.00

0.00

0.00

0.00

0.00

74.99

0.00

HSH

0.00

0.00

0.00

0.00

0.00

45.19

0.00

0.00

0.00

HOH

0.90

1.82

0.96

0.47

0.00

0.00

80.48

0.00

0.00

HWWH

3.12

0.85

0.13

0.06

0.52

0.16

0.11

0.00

0.00

HWOH

4.67

7.05

0.96

0.33

1.79

0.80

0.37

0.00

0.00

HWRH

1.64

1.46

0.18

0.02

0.86

1.56

0.09

0.00

0.00

HWOH

0.08

0.04

0.00

0.00

0.00

0.00

0.00

0.00

0.00

HSWH

0.00

0.00

0.00

0.00

0.16

0.00

0.00

0.00

0.00

HSSH

0.00

0.00

0.00

0.00

0.11

0.00

0.00

0.00

0.00

HSPH

0.00

0.00

0.00

0.00

0.97

0.00

0.00

0.00

0.00

HSRPH

0.00

0.00

0.00

0.00

0.00

0.23

0.00

0.00

0.00

HSRRH

0.00

0.00

0.00

0.00

0.00

0.55

0.00

0.00

0.00

HSRSH

0.00

0.00

0.00

0.00

0.00

0.76

0.00

0.00

0.00

HSSOH

0.00

0.00

0.00

0.00

0.00

0.17

0.00

0.00

0.00

HSSSH

0.00

0.00

0.00

0.00

0.00

0.12

0.00

0.00

0.00

HOWWH

0.01

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

HOWPH

0.01

0.04

0.00

0.00

0.00

0.00

0.00

0.00

0.00

HOWRH

0.01

0.00

0.00

0.00

0.00

0.00

0.03

0.00

0.00

HOWOH

0.00

0.00

0.00

0.00

0.00

0.00

0.12

0.00

0.00

HOPPH

0.00

0.00

0.00

0.00

0.00

0.00

0.25

0.00

0.00

HOPRH

0.00

0.00

0.00

0.03

0.00

0.00

0.14

0.00

0.00

HOPOH

0.00

0.00

0.00

0.00

0.00

0.00

0.04

0.00

0.00

HPRRH

0.00

0.00

0.00

0.01

0.00

0.00

0.17

0.00

0.00

HOROH

0.00

0.00

0.00

0.00

0.00

0.00

0.11

0.00

0.00

HOOOH

0.00

0.00

0.00

0.00

0.00

0.00

0.03

0.00

0.00

Table 44: List of the activity chains: mobility rates per person group in %

PTV AG

163

Chapter 3: Demand model

The sum of the probabilities of a person group is often greater than 1.0 (or 100 %), because a
person can complete more than one activity chains one after the other in a day (for example,
person group E+c first HWH, then HRH).
The list displayed above, describes an average mobility for persons depending on the group
they belong to. In the tour-based model, trip generation (i.e. determining the absolute number
of activity chains and thus the trips starting from any of the individual zones) is calculated by
multiplying the inhabitants of each person group with the probabilities of all activity chains. Trip
generation can be limited to the active zones.
Thus, in the tour-based model, trip generation (the number of trips created with each activity in
the activity chain) is determined together with the number of inhabitants and distribution of
person groups. The result is saved in the zone attribute Home trips for each demand strata.

Example of trip generation with the tour-based model


2,000 employees with a car (E+c) live in zone 1. After the activity chain distribution above, run
the activity chain HWOH per day with 4.67 % probability. This is why there are 2,000 4.67 %
= 93.4 chains of the type HWOH. Consequently, home trips for the demand stratum E+c x
HWOH add up to 93.4.
The 2,000 persons in this activity chain produce a total of 3 93.4 = 280.2 trips, namely 93.4
HW trips and just as many for WO and OH.

3.2.3.3

Tour-based model: trip distribution / mode choice combined

Using tour-based calculation, you can save output matrices with different aggregation levels.
The demand matrices are calculated from possible combinations of person group, mode,
production and attraction activity, and time interval.

Trip distribution: route links through destination choice according to activities


Depending on the destination activity of a trip, the tour-based model assigns it to a destination
zone. This destination zone is chosen depending on several factors.

The utility matrix, which shows the separation from the origin zone (spatially and trafficwise)
The utility is inversely proportional to impedance values, such as run times or distances, so
that the greater the run time or distance to a destination zone, the less its utility.
The utility matrix may also include the log sum of mode-specific use. In this way, specific
skims (e.g. PrT journey time or PuT number of transfers) are included in the total utility with
their share in the respective mode.

The target potential of the zones competing as destinations


The impact of utility defined via the utility function parameters for each group and each
destination activity
These parameters can be estimated beforehand (see "Estimate gravitation parameters
(KALIBRI)" on page 173)

This is how a multitude of trip chains is created through each activity chain. The result of trip
distribution is not only a total traffic matrix, but also a set of all route chains.

164

PTV AG

Chapter 3.2: Demand modeling procedures

With the destination choice model, the tour-based model needs a target potential Zj for each
activity. The target potential specifies the quantitative attractiveness of a zone. This target
potential for each zone j, corresponds to the value of the structural property (see "Tour-based
data model" on page 161) that belongs to the activity.
The utility function f(uij) is pivotal in the destination choice model. It specifies the probability Pij
with which one of the zones j is selected as destination zone (from all destination alternatives)
of origin zone i.

F ij = Q i P ij
Z j f ( u ij )
P ij = -----------------------------------------B

k = 1 Z k f uik

whereby

Fij

Number of trips from zone i to zone j

Qi

Productions in zone i

Pij

Choice probability of destination j for origin zone i

Zj

Target potential in zone j

Index of zones (with k = the smallest zone number and B = the number of zones)

whereby uij describes the utility relation ij and the utility function f(uj)) (e.g. of the type Logit) can
consequently be defined as f ( u ij ) = e

cu ij

. All other evaluation functions of the EVA demand

model can also be used as utility functions in the tour-based model (see "EVA trip distribution
and mode choice" on page 152).
In this case, the choice of parameter c for every activity is pivotal for destination choice. c
stands for the influence of utility on the destinations of the respective activity. If c = 0, then the
utility uij has no influence on the choice of destination. The larger c is, the larger is the impact
of utility uij on the choice of the destination (see "Gravity model calculation" on page 174).
You define function parameters for each person group.
To give you a better idea of what the three main model elements of destination choice, namely
destination potential, utility function and utility matrix, stand for, we will continue with the
example we used for trip generation (see "Example of trip generation with the tour-based
model" on page 164).

Example of trip generation


A Logit utility function ( f ( u ij ) = e

cu ij

with parameter c = 0.4) is used to represent the

changeovers from and to the individual activities.


The 93.4 trips of the activity pattern HW have to lead from the origin (zone 1) to the potential
destination zones, containing jobs. The tour-based model distributes these 93.4 trips to the
destination zones, according to the previously described destination choice model.

PTV AG

165

Chapter 3: Demand model

To make it easier, let us assume that zone 2 is the only zone with jobs, which therefore has a
positive destination potential for the activity work. Expressed in numbers this would be
approximately Z1 = 0, Z2 = 100, Z3 = 0. The tour-based trip distribution formulas produce the
following results P11 = 0, P12 = 1 and P13 = 0, and therefore F11 = 0, F12 = 93.4 and F13 = 0.
Zone 2 is therefore the destination of all trips of zone 1.
Note: The definition of the utility function in this case does not influence the calculation.
After the activity work, based on zone 2, the probability for the choice of shopping destinations
is calculated for the subsequent trips WO. It is assumed, that the destination potentials for the
activity "Shopping" are defined as follows: Z1 = 0, Z2 = 50, Z3 = 50. Based on travel times and
distances, the utility defined for changeover WO, with the relation 2-2, is twice as high as the
changeover with the relation 2-3, thus approximately u22 = 2 and u23 = 1. The tour-based trip
distribution formulas produce the following results P21 = 0, P22 0.6 and P23 0.4, and
therefore F21 = 0, F22 56.0 and F23 37.4. 40 % of the trips thus lead to zone 3 and 60 % to
zone 2 (i.e. trips within the cell).
Here, multiplication of the destination probability of the work and shopping destinations takes
place in the system.
For the last activity pair of the chain, namely PH, destination choice is no longer necessary,
because zone 1 as a residential district and origin of the first trip of the chain, is also the
destination of the last trip of the chain.
This results in the following transition matrices.

Zone

93.4

93.4

Total

93.4

93.4

93.4

166

Matrix F1 for the first activity transfer (Destination activity W)


1

Matrix F2 for the second activity transfer (Destination activity O)

Zone

93.4

93.4

Total

56.0

37.4

93.4

56.0

37.4

PTV AG

Chapter 3.2: Demand modeling procedures

Matrix F3 for the third activity transfer (Destination activity H)

Zone

93.4

93.4

Total

93.4

56.0

56.0

37.4

37.4

Summed up, the following total demand matrix applies FG.


Zone

280.2

280.2

Total

93.4

149.4

37.4

93.4

93.4

149.4

56.0

56.0

37.4

37.4

37.4

Summary of this destination choice example

HW: 100 % leave zone 1 with destination zone 2


WO: 60 % remain in zone 2 and 40 % leave zone 2 to zone 3
OH: 100 % return to zone 1.

The corresponding route chains are as follows:

1-2-2-1: 93.4 100 % 60 % 100 % = 56.0


1-2-3-1: 93.4 100 % 40 % 100 % = 37.4

The following route chains have been created:

56.0 route chains 1-2-2-1


37.4 route chains 1-2-3-1

Notes: The following behavioral aspects should be taken into consideration when you define
the utility parameters.
Traffic behavior analyses show, that persons with a car cover greater distances than
persons without a car. Accordingly, the absolute value of parameter c of the Logit function
for groups E+c and NE+c have to be smaller than for groups E-c or NE-c.
This also complies with the empirical perception, to give activity Work a c parameter with
a low absolute value, rather than for example activity Shopping.
The tour-based model allows specific utility matrices to be imported for each activity.
Combinations of distances and journey times can be used as a basic parameter in utility
matrices.

PTV AG

167

Chapter 3: Demand model

Note: The absolute value of a destination potential is first of all irrelevant, because it only
flows into the destination choice model comparatively to the sum of destination potentials of
all zones. Destination potential " jobs = 1,000" for a zone does not necessarily mean that the
tour-based model produces 1,000 trips for destination activity work. In fact, the destination
traffic depends on the product of destination potential and utility function value in relation to
the other zones.
If, however, the absolute value of the destination potential of an activity is very important, as for
example for the number of jobs, this can flow into the calculation via the Destination-sided
attraction option. If there are approx. 6,000 jobs in the study area, 1,000 jobs mean there is a
relative destination potential of 1,000/6,000 = 1/6 for the activity work. If a demand stratum has
a total of 3,000 home trips, the absolute zone destination potential standardized to the total of
home trips for this demand stratum is 3 1/6 = 500. This absolute value for the demand stratum
is used as a constraint in the doubly coupled gravity model (see "Gravity model calculation" on
page 174).
You can save your trip distribution results in an aggregated form to total demand matrices per
person group as well as per combination of time interval, mode, origin and destination activity.

Mode choice: discrete distribution model


The tour-based demand model has a behavior-oriented concept, which models the following
aspects of the decision-making of road users.

The socioeconomic position and the mode availability of the person making the decision
(by differentiating according to person groups)
Different attributes of all modes (through the utility model)
Freedom of choice restrictions within trip chains (by definition of exchangeable and nonexchangeable modes)

This decision problem is illustrated in a discrete distribution model, which specifies the
probability for mode choice in every available route link.
To do so, the subjective use has to be calculated in dependency of the mode skims (in-vehicle
time, access and egress times, fare, etc.). If required, you can define several utilities per
destination activity.
This model has the following functional form.

f ( u ijm )
P ijm = -----------------------------M

k = 1 f ( uijk )

whereby

168

i, j
m

Indices of the traffic zones

Pmij

Probability of selecting mode m for trip from i to j

umij

Utility when choosing mode m for trip from i to j

Index of modes (M = total number)

PTV AG

Chapter 3.2: Demand modeling procedures

f ( u ijm ) can e.g. be a Logit utility function and thus be defined as f ( u ijm ) = e cu ij . As an
alternative, all available types of evaluation functions can be used from the EVA demand
method as a utility function for the tour-based mode choice (see "EVA trip distribution and
mode choice" on page 152).
As a base parameter for the utility matrices any distance combinations and mode specific
skims can be used, such as travel times, access and egress times, and fares. You can also use
the LogSums of mode-specific use as an input parameter.
Last but not least, we would like to explain the importance of the route chain concept for mode
choice.
In Visum the modes are divided into the following groups:

exchangeable modes (generally walk, passenger and public transport)


non-exchangeable modes (car, bike)

The tour-based model calculates a discrete distribution model (for example Logit) when first
calculating the trip of each route link (for a person group) and chooses one from all modes. If
the first mode is a non-exchangeable mode, the entire trip chain is maintained independent of
the attributes of this mode of the successive trip. If an exchangeable mode was selected for the
first trip, mode choice is carried out for the remaining chain trips, however, only within the
exchangeable modes.

Example of mode choice


We will continue with the example from the trip distribution (see "Example of trip generation" on
page 165) and will determine the matrices for each activity transfer for the three modes Car
(C), PuT (X) and Walk (W). Only mode P cannot be exchanged. The set of exchangeable
m

modes X and W in short is also designated with A. A Logit utility function f ( u ijm ) = e cuij (with
parameter c = 0.4) is used again to represent the changeovers from and to the individual
activities. The utility matrices um for each mode m are provided by

Zone

PTV AG

uC

uX

Zone

169

Chapter 3: Demand model

uW

Zone

After analyzing the formula above, the following probability matrices apply.

PC

Zone

0.472

0.526

0.526

0.526

0.472

0.472

0.526

0.472

0.472

Zone

PX

0.316

0.237

0.237

0.237

0.316

0.316

0.237

0.316

0.316

Zone

PW

0.212

0.237

0.237

0.237

0.212

0.212

0.237

0.212

0.212

PA = PX + PW

Zone

0.528

0.474

0.474

0.474

0.528

0.528

0.474

0.528

0.528

Interesting are also the probabilities for modes X and W within the exchangeable modes.

PAX = PX / PA

Zone

170

0.598

0.5

0.5

0.5

0.598

0.598

PTV AG

Chapter 3.2: Demand modeling procedures

Zone

0.5

0.598

0.598

PAW = PW / PA

Zone
1

0.402

0.5

0.5

0.5

0.402

0.402

0.5

0.402

0.402

The matrix of the first non-exchangeable mode Car for all activity transfers is calculated. The
matrix for the first activity transfer is the product of PC with the total demand matrix F1 of the
first transfer.

Total demand matrix F1 for the first activity transfer (Destination activity W)

Zone

93.4

93.4

Total

93.4

93.4

93.4

Matrix FP1 for mode C and the first activity transfer (destination activity A)

Zone

49.12

49.12

Total

49.12

49.12

49.12

With the next activity changeover, these 49.12 trips will be distributed across zones 2 and 3
according to the distribution probabilities (P22 = 0.6 or P23 = 0.4).

Matrix FC2 for mode C and the second activity transfer (Destination activity O)

Zone

49.12

49.12

Total

29.47

19.65

49.12

10

29.47

19.65

Finally, the trips have to end back at the last activity transfer in their origin zone 1.

PTV AG

171

Chapter 3: Demand model

Matrix FC3 for mode C and the third activity transfer (Destination activity H)

Zone

49.12

49.12

Total

49.12

29.47

29.47

19.65

19.65

Summed up, the following Car total demand matrix applies: FCT
Zone

147.36

147.36

Total

49.12

88.59

19.65

49.12

49.12

88.59

29.47

29.47

19.65

19.65

19.65

To determine the total demand matrix for non-exchangeable modes, this Car matrix is
subtracted from the total demand matrix FT (from trip distribution).

FT

Zone

280.2

280.2

Total

93.4

149.4

37.4

93.4

93.4

149.4

56.0

56.0

37.4

37.4

37.4

The difference first results in the total demand matrix for all non-exchangeable modes.

FA

Zone

132.84

132.84

Total

44.28

70.81

17.75

44.28

44.28

70.81

26.53

26.53

17.75

17.75

17.75

For this matrix mode choice now takes place within the exchangeable modes PuT and Walk,
to obtain the total demand matrices for modes PuT and Walk. The matrix is multiplied with the
probabilities PAX and PAW.

172

PTV AG

Chapter 3.2: Demand modeling procedures

PuT total demand matrix FX

Zone

70.75

70.75

Total

22.14

38.00

10.61

22.14

22.14

39.74

13.27

15.86

10.61

8.87

8.87

Walk total demand matrix FW

Zone

62.09

62.09

Total

22.14

32.81

7.14

22.14

22.14

31.07

13.26

10.67

7.14

8.88

8.88

Make sure that the Car total demand matrix has identical row and column sums for each zone,
whereas this is not mandatory for the PuT and Walk matrices.
The mode choice results are saved in an aggregated form to demand matrices per person
group and mode. In addition, you can limit the usage of time interval and origin and destination
activity data for matrices with disaggregated data.

3.2.4

Estimate gravitation parameters (KALIBRI)


The Estimate gravitation parameters function (short KALIBRI) allows you to calibrate two
different utility functions (determine parameters a, b and c) for the gravity model used for trip
distribution.
1.

( )

f U ij = a U ij b e

c U ij

whereby

Uij

Value of the utility (for example distance or travel time) between zone i and zone j

a,b,c

Parameters to be estimated

2.

( )

f U ij = a e

cU ij

whereby

Uij

Value of the utility (for example distance or travel time) between zone i and zone j

a,c

Parameters to be estimated

The KALIBRI function adjusts these utility functions to a given trip length distribution.

PTV AG

173

Chapter 3: Demand model

Then the Trip distribution function calculates the traffic flow Fij (from zone i to zone j) with the
aid of the gravity model and known data, namely the source traffic Qi (of zone i), destination
traffic Zj (of zone j) and the parameters a, b, c (or a, c) specified here (see "Gravity model
calculation" on page 174).
The KALIBRI function provides two options that allow you to estimate the parameters for the
gravity model.

singly constrained production


doubly constrained (Multi procedure)

Parameters a, b, c or a, c respectively are determined in an iterative process. The utility function


is transformed during this process; with

( )

(2)

( )

(3)

ln f U ij = ln a + b ln U ij + c U ij
or

ln f U ij = ln a + c U ij

Within each KALIBRI iteration a temporary demand matrix is calculated (for example via Multi
procedure with option doubly-constrained gravity model). The resulting values of the utility
function are smoothed by linear regression until the maximum number of KALIBRI iterations is
reached or the values do not change anymore. The smoothed values then describe a function
of type (2) or type (3).

3.2.5

Gravity model calculation


The Gravity model is a mathematical model for trip distribution calculation (see "Trip
distribution" on page 129 and "Tour-based model: trip distribution / mode choice combined" on
page 164). It is based on the assumption that the trips made in a planning area are directly
proportional to the relevant origin and destination demand in all zones and the functional
values of the utility function between the zones (Ortzar 2001).
The gravity model calculates a complete matrix of traffic relations Fij, using the OD pairs of
marginal totals (origin and destination traffic of the individual zones). A consistent utility matrix
of the planning region is required.
The gravity model works with distribution parameters, therefore with values within the utility
function, which map the reaction of road users to distance or time relations. These parameters
are determined by comparing the demand per OD pair arising from the model, with the counted
demand per OD pair (calibration).
The capability of the models to predict future conditions (forecasting) depends on whether they
manage to predict the behavior of road users in relation to the network impedances, as well as
knowledge of the model input data applicable for the future (for example future travel demand).
General form of the distribution formula

F ij = k ij Q i Z j f ( U ij ) whereby
Logit

174

f ( U ij ) = e

cU ij

PTV AG

Chapter 3.2: Demand modeling procedures

Kirchhoff

f ( U ij ) = U ij

Box-Cox

f ( U ij ) = e
Combined

U ij 1
c -----------------b

f ( U ij ) = a U ij e

TModel

cU ij

1
f ( U ij ) = ---------------------------b
a
U ij + cU ij

The distribution formula is referred to an attraction or utility function, with the following
parameters.

Uij

Value for the utility between zones, for example distance or travel time from zone i to zone j

Qi

Origin zone i

Zj

Destination zone j

kij

Scaling factor (attractiveness factor) for OD pair zone i to zone j

Number of zones

Determining the scaling factor kij and formulating the utility function f(Uij) are essential for
various modifications and extensions.
The scaling factor kij must be chosen so that the boundary conditions of the distribution models
n

j = 1 Fij

= Qi

(4.1)

= Zj

(4.2)

and
n

i = 1 Fij

are (at least approximately) fulfilled.


Retaining only the first direction of distribution, we speak of production distribution. Retaining
only the second direction of distribution, we speak of attraction distribution. Retaining both
directions of distribution at the same time, we speak of doubly constrained. For coupling in

terms of production kij only depends on i, so we write k i .


For logical reasons, coupling for production requires that there are as many free parameters as
there are zones.
This leads to the formulation

F ij = k i Q i Z j f ( U ij )
with the following secondary conditions for zone i.
n

j = 1 Fij
PTV AG

= Qi

175

Chapter 3: Demand model

From the n secondary conditions, all ki can thus be determined by substitution in the
distribution function:
n

Qi =

j = 1

F ij =

j = 1

k i Q i Z j f ( U ij ) = k i Q i

j=1

Z j f ( U ij )

This results in

1
k i = ------------------------------------------ for Qi 0
n

j' = 1 Zj' f ( Uij' )

This produces a destination choice model of production distribution.

Q i Z j f ( U ij )
F ij = ------------------------------------------ for all i, j
n

j' = 1 Zj' f ( Uij' )

The destination choice model of attraction distribution is derived analogously.

Q i Z j f ( U ij )
1
F ij = ------------------------------------------- for all i, j with k j = ------------------------------------------n

i' = 1 Qi' f ( Ui'j )

i' = 1 Qi' f ( Ui'j )

The adjustment of the model to reality (calibration) by variation of the free parameters is very
important.
Since the input parameters Qi and Zj have been specified, the only free parameters that remain
besides the scaling factors ( k and k ) are the parameters of the utility function f(Uij .
i

Since for doubly constrained calculation both directions of the distribution, (4.1) and (4.2) must
be met at the same time, the following must also apply for the scaling factors k and k as well
i

as k i = kj for i = j. In practice, however, this can seldom be achieved, so a true doubly-

constrained calculation can only be achieved with much more complex iteration models.
As an iteration model the Matrix Editor uses the so-called Multi procedure according to Lohse
(Schnabel 1980) (see "The multi-procedure according to Lohse (Schnabel 1980)" on
page 189).
The general form of the utility function f(Uij) is
b

f ( U ij ) = a U ij e

cU ij

It is depicted for several b and c parameters in the following two figures.

176

PTV AG

Chapter 3.2: Demand modeling procedures

Attractiveness with a = 1 and b = 0


1
0,9

f(Uij)

0,8
0,7

c = -0,01

0,6

c = -0,1

0,5
0,4

c = -0,3
c = -0,5

0,3

c = -1

0,2
0,1
0

Uij
0

10

12

14

16

18

20

Utility between zone i and zone j

Attractiveness with a = 1 and c = -0,1


2
1,8
1,6
1,4
b = 0,1

f(Uij)

1,2

b = 0,3

b = 0,5

0,8

b = 0,7

0,6
0,4
0,2
0

Uij
0

10

15

20

25

30

35

40

Utility between zone i and zone j

Notes: Choose a suitable specification for the utility functions, which means suitable
parameters. Among other things, the specification depends on the trip purpose and the mode
used. A trip to work is for example, on average longer than a trip for shopping. This means
that the utility function for the trips to work, depending on the town's size, is only slightly
dependent on the use (distance or travel time) or not at all. Shopping trips on the other hand,
are much more dependent on the use.
The use of a trip distribution model can therefore call for a separation of the travel demand
based on the trip purpose. This depends essentially on the requirements in terms of accuracy
and the demands on the matrix to be calculated. Benchmark figures for the percentage split
based on the trip purpose can be obtained for example from the KONTIV 89 (EMNID 1991)
or local surveys.
The following four examples show gravity models that are differently constrained and with and
without balancing.

Example 1: Gravity model singly constrained in terms of production, with and


without balancing
The effect of the location factor on the calculation of the trip distribution according to the gravity
model depends on the type of coupling of the gravity model.

PTV AG

177

Chapter 3: Demand model

With the distribution method that includes coupling for EITHER attraction or production, the
source or destination traffic is adjusted to the marginal totals in the code file. The location factor
then only affects the "complementary" destination or origin demand. However, the following
applies
n

j = 1 Zj

i = 1 Q i k i

or

i = 1 Q i

j = 1 Zj kj

whereby ki or kj are attractiveness factors of the i or j zone.


With the distribution method that includes coupling for attraction AND production, the impact of
the attractiveness factor on the origin and destination traffic depends on the function command
in the code file. If for example $GQH is given as function command, the origin demand is
changed by the location factor that is listed in the same line as the factor within the code file.
However,
n

j = 1 Zj + i = 1 Qi ki

i = 1 Qi = j = 1 Z'j ----------------------------------------------------------2

with ki being the attractiveness factor of the i zone.

Input file Utility

Zone numbers
1
2.66

*
*

1.00
0.33
0.33
1.00

2
1.75
2.08
0.50
2.33
0.50
1.41
0.25
2.08
0.50

3
1.99

4
1.50

0.33

0.25

1.00

0.50

0.33

0.50

0.33

0.25

* 7.90

Input data for calculation without balancing

*Zone
1
2
3
4

Production
10.0000
20.0000
30.0000
40.0000

Attraction
50.0000
10.0000
20.0000
20.0000

Factor
0.50000000
1.00000000
1.00000000
1.00000000

External
0
0
0
1

The parameters are set as follows:

178

Combined utility function (exponential)


Parameter a = 1, b = 0.5 and c = -1
Singly-constrained for production without balancing

PTV AG

Chapter 3.2: Demand modeling procedures

Result matrix

Zone numbers
1
36.76

*
*

2
15.91
10.00
3.11
1.45
20.01
6.76
2.81
30.00
9.97
3.76
40.00
16.92
7.89

3
30.79

4
16.55

2.80

2.64

4.82

5.62

7.98

8.29

15.19

0.00

100.01

Input data for calculating balancing and scaling according to average value

*Zone
1
2
3
4

Production
10.0000
20.0000
30.0000
40.0000

Attraction
50.0000
10.0000
20.0000
20.0000

Factor
0.50000000
1.00000000
0.30000000
1.00000000

External
0
0
0
1

The parameters are set as follows:

Direction of the distribution according to the production distribution with boundary sum
balancing enforced by the multi procedure.
Combined utility function (exponential)
Parameter a = 1, b = 0.5 and c = -1
Scaling according to mean value of both sums
Max. number of iterations = 10, Quality factor = 3
Result matrix

Zone numbers
1
32.99

2
13.19
8.04
2.22
0.94
16.10
4.62
1.74
24.16
6.95
2.38
32.19
19.20
8.13

*
*

80.49

3
7.92

4
26.39

0.56

4.32

0.93

8.81

1.57

13.26

4.86

0.00

Example 2: Gravity model singly-constrained for production, with balancing

Input file Utility

Zone numbers

*
*

PTV AG

1
2
166.183 107.560
165.571
0.001
22.700
107.414
22.700
0.001
90.008
35.926
16.284
134.633
50.387
31.017
155.524
57.169
37.558

3
88.972

4
134.710

5
155.725

35.183

50.387

57.300

15.991

31.017

37.705

0.001

15.153

22.644

15.153

0.001

38.075

22.644

38.152

0.001

653.150

179

Chapter 3: Demand model

Input data

*Zone
1
2
3
4
5

Production
18990.0
4960.0
7110.0
16080.0
2300.0

Attraction
18990.0
4960.0
7110.0
16080.0
2300.0

Location factor and zone property external are not specified. Default values are used.
The parameters are set as follows:

Direction of the distribution according to the production distribution with boundary sum
balancing enforced by the multi procedure.
Combined utility function (exponential)
Parameter a = 1, b = 0.5 and c = -1
Scaling according to the production total
Max. number of iterations = 10, Quality factor = 3
Result matrix

Zone numbers

*
*
*
*
*
*
*

1
2
18990.000 4959.951
1
18990.000
18990.000
0.000
2
4959.999
0.000 4959.897
3
7110.000
0.000
0.054
4
16080.000
0.000
0.000
5
2300.000
0.000
0.000
49439.999

3
4
7109.758 16080.290

5
2300.000

0.000

0.000

0.000

0.102

0.000

0.000

7109.426

0.520

0.000

0.230 16079.770

0.000

0.000

0.000

2300.000

Example 3: Gravity model singly-constrained for attraction, without balancing

Input file impedances

* Zone numbers
1
2
1.00
0.50
0.33
0.50
0.33
0.25
1.00
0.50

3
0.33
1.00
0.33
0.33

4
0.25
0.50
0.50
0.25

Input data for marginal totals

*Zone
1
2
3
4

Production
10
20
30
40

Attraction
50
10
20
20

The parameters are set as follows:

Singly-constrained for attraction, without balancing


Combined utility function (exponential)
Parameter a = 1, b = 0.5 and c = -1
kj = 1 for all j

This produces the following function values of utilities f(Uij)


Zone
1

180

1
0,37

2
0,43

3
0,41

4
0,39

PTV AG

Chapter 3.2: Demand modeling procedures

2
3
4

0,41
0,41
0,37

0,43
0,39
0,43

0,37
0,41
0,41

0,43
0,43
0,39

Q 1 Z 1 f ( U 11 )
and so F 11 = -----------------------------------------n

i = 1 Qi f ( Ui 1 )

10 50 0.37
F 11 = ----------------------------------------------------------------------------------------------------------------10 0.37 + 20 0.41 + 30 0.41 + 40 0.37

F11 = 4.71
The matrix is produced after the other 15 equations have been calculated.

Result matrix

Zone numbers
1
50.00

*
*

99.98

2
10.00
9.68
4.71
1.03
20.47
10.58
2.06
31.09
15.87
2.80
38.74
18.84
4.11

3
19.99

4
19.99

2.04

1.90

3.64

4.19

6.13

6.29

8.18

7.61

The desired values for destination demand were very well approximated, while the values for
origin demand were not reached so well. This circumstance is characteristic for such
distribution formulas. Either the origin or the destination sums are reached close enough. If
both boundary sums are to be aligned as closely as possible, it is necessary to use a boundary
compensation model. The function offers doubly constrained projection (Multi-Procedure) (see
"Projection" on page 188).

Example 4: Gravity model singly-constrained for attraction, with balancing


Now the trip distribution in Example 3 (see "Example 3: Gravity model singly-constrained for
attraction, without balancing" on page 180) shall be calculated using a balancing procedure
(Multi-procedure).

Input file impedances

* Zone numbers
1
2
1.00
0.50
0.33
0.50
0.33
0.25
1.00
0.50

3
0.33
1.00
0.33
0.33

4
0.25
0.50
0.50
0.25

Input data

* ZoneNo
1
2
3
4

Productions
10
50
20
10
30
20
40
20

Attractions

The parameters are set as follows:

PTV AG

Direction of the distribution according to the production distribution with boundary sum
balancing enforced by the multi procedure.
Combined utility function (exponential)

181

Chapter 3: Demand model

Parameter a = 1, b = 0.5 and c = -1


Scaling according to mean value of both sums
Max. number of iterations = 10, Quality factor = 3
Result matrix

Zone numbers
1

3.2.6

1
50.00

*
*

2
10.01
10.01
4.87
1.06
20.00
10.34
2.01
30.00
15.32
2.70
40.00
19.47
4.24

3
20.00

4
20.00

2.11

1.97

3.55

4.10

5.91

6.07

8.43

7.86

100.01

Iteration
Iteration allows the repetition of the different steps of a procedure and therefore can be used to
re-incorporate skims calculated during the assignment into previous stages.

3.2.6.1

Go to procedure

Use the Go to procedure to carry out a convergence check. You can choose between the
following checks
1. It is checked whether, during the last iteration, attribute or matrix data has changed by less
than the user-defined threshold value. To find the values that have changed, the following
formula is used:

ABS ( X ( n ) X ( n 1 ) ) > MIN ( a M AX ( X ( n ), X ( n 1 ) ) + b, c ) )


with
a
b
c

factor of relative deviation


tolerance value
absolute value for maximum change

The following figure shows how the tolerance value is applied. For smaller attribute values, it
allows for acceptance of larger relative deviations than for larger attribute values. In
illustration 55, the green curve represents the relative deviation, whereby the tolerance value
was considered part of the attribute value.

182

PTV AG

Chapter 3.2: Demand modeling procedures

Illustration 55: Application of tolerance value in Go to procedure

2. It is checked whether a user-defined attribute lies under a specific value. This is useful
when you first add a script that recalculates the respective value.
If the convergence condition has been fulfilled, Visum continues with the next step of the
procedure. If not, Visum returns to the point specified as Go to target (procedure or group) and
iterates the procedure from there (procedure) or from the next step (group). Independent of
this, the convergence check is canceled as soon as a maximum number of iterations is
reached.

3.2.6.2

Method of successive averages over matrices

Using MSA (method of successive averages), you can calculate the mean value of two
matrices (demand or skim matrices).
This function is meant to improve convergence in demand models used for feedback. You can
add it prior to the Go to procedure if you want to use an averaged matrix of all iterations
instead of a matrix of the current iteration as a GoTo criterion.
The operation calculates

i
1
A = ----------- B + ----------- C
i+1
i+1
whereby

A
B
C
i

Result matrix
Matrix of current iteration
Matrix average of all previous iterations
iteration counter

Notes: The iteration counter starts counting from iteration 0 and when Go to procedures are
triggered it always uses the innermost loop as point of reference.

PTV AG

183

Chapter 3: Demand model

3.2.6.3

Method of successive averages over attributes

As for matrices the average values of attributes can be determined by means of MSA (Method
of Successive Averages), too.
This function is meant to improve convergence in demand models used for feedback. You can
add it prior to the Go to procedure if you want to use the average values of attributes of all
iterations instead of the attribute values of the current iteration as a GoTo criterion.
The operation calculates

i
1
A = ----------- B + ----------- C
i+1
i+1
whereby

A
B
C
i

newly calculated attribute value


Attribute value of current iteration
Averaged attribute value of all previous iterations
iteration counter

Notes: The iteration counter starts counting from iteration 0 and when Go to procedures are
triggered it always uses the innermost loop as point of reference.
During an operation you can exchange the two weightings.

3.3

Displaying and editing matrices


Visum provides various options for displaying and editing matrices or using them for
calculations.
Functions used to display and analyze matrices
Highlighting matrix sections in color
Showing matrix values in an aggregated form
Filtering matrix values
Displaying matrix values as a histogram
Comparing matrices graphically in pairs

Visum offers both simple and more complex operations for editing and calculating matrices.
Most operations can be performed directly in the Matrix editor (see User Manual, Chpt. 3.3,
page 823), others are available as procedures (see User Manual, Chpt. 4, page 937).
Functions for copying / replacing matrix values

184

Matrix editor
window

Procedure

Edit individual matrix values interactively

Set values conditionally

x*

Form constant matrix

x*

PTV AG

Chapter 3.3: Displaying and editing matrices

Functions for copying / replacing matrix values

Matrix editor
window

Procedure

Transpose

Reflect upper or lower triangle

Set diagonal

x*

Copy diagonal to clipboard


Paste diagonal from clipboard

Arithmetic operations on matrices

x*

Matrix editor
window

Procedure

Round

Add / subtract matrices

x*

Multiply / divide matrices (element-wise)

x**

Form reciprocal (element-wise)

Raise to power (element-wise)

x**

Take logarithm (element-wise)

Exponential function (element-wise)

Forming maximum or minimum

Symmetrize matrix (calculate average values pairwise from top and bottom
triangle)

Combination of matrices and vectors

Projection: various procedures

Projection of aggregated areas

Calculate matrix using marginal totals, i.e. trip distribution (see "Gravity
model calculation" on page 174)
Generate main zone matrix, using zone matrix (aggregate) - and
generate zone matrix, using main zone matrix (disaggregate)

x
x

* Not a procedure of its own, but possible via Combination of matrices and vectors
** Possible in procedures via add-in CalculateMatrix
Functions for structural changes to matrices
Extend matrix (include new OD pairs in matrix for arithmetic operations)
Aggregate (summarize rows/columns of a matrix)
Split/Extend (rows/columns of a matrix into/to several ones)
Form partial matrix (non-symmetric aggregation)

3.3.1

Displaying matrices in tabular form


There are different ways to organize matrix data in a clear way. In Visum, in the Matrix editor
window, you can change the data display to gain a better overview of your data (see User
Manual, Chpt. 3.3, page 823):

PTV AG

185

Chapter 3: Demand model

3.3.2

You can show matrix data in the matrix or list view.


You can open several matrices in a window so that the corresponding values of the
matrices are positioned side by side.
In addition to the matrix values, it is possible to display the row and column headers as well
as the row and columns totals.
You can change the alignment of the values and the number of the displayed decimal
places.
You can classify the matrix values and display the values of different classes in different
font and background colors.
You can filter the matrix data by active zones, pairs of zones or by specific matrix values,
so that only the rows and columns of your choice are shown.
You can use aggregate functions to show the matrix data aggregated according to
attributes of origin or destination zones, without having to change any data manually.
You can save filtered or aggregated matrix data as a file and continue to use it in Visum as
an external matrix.

Displaying matrix values as a histogram


This function allows you classify the values of one or several matrices and to display them as
column chart. You define intervals for the classification of the matrix values. You can determine
the intervals interactively or import them from a file (see User Manual, Chpt. 3.3.13, page 854).
It is also possible to classify the matrix by using a comparison matrix that must include identical
zones. The OD pairs are divided into the defined intervals based on the comparison matrix.
The matrix values of the input matrix will then be summarized per interval according to this
allocation.
In addition to the histogram a list is displayed showing the number and the percentage of OD
pairs for both, each interval and cumulative for all intervals. If the matrix is changed, the results
will be updated automatically.
This function serves for analyses of existing data for further matrix processing steps, for
example aggregating data (see "Aggregating matrix objects" on page 192). The intervals can
be stored and used for other applications.

3.3.3

Comparing matrices graphically in pairs


In a special window, you can have the data of two matrices displayed along the x and y axis of
a scatter plot. The plot further contains a diagonal, the regression line and the parameters of
the regression function. The shape and position of the point cloud show similarities and
deviations between the matrix values (see User Manual, Chpt. 3.3.14, page 857).

3.3.4

Transpose, reflect upper or lower triangle, apply mean value


The Transpose function allows lines and columns of a matrix to be interchanged, which means
that the values of the rows become the values of the columns and vice versa. The resulting
matrix consequently contains the values of the opposite direction of the input matrix, with
unchanged values in the diagonal. This function is used, for example, to generate a matrix of
the outgoing traffic from a matrix of the incoming traffic (see User Manual, Chpt. 3.4.9,
page 873).

186

PTV AG

Chapter 3.3: Displaying and editing matrices

The Reflect lower triangle function offers the option of copying the matrix section below the
diagonal into the upper triangle (see User Manual, Chpt. 3.4.8, page 872). The Reflect upper
triangle function offers the option of copying the matrix section above the diagonal into the
lower triangle (see User Manual, Chpt. 3.4.7, page 871).

3.3.5

Copy, paste and apply diagonal


Note: The diagonal of a matrix runs from top left to bottom right (FromZoneNo = ToZoneNo).
In demand matrices the diagonal represents the trips within the cell.
The functions Copy diagonal into clipboard and Paste diagonal from clipboard enable the
exchange of diagonal values between two matrices. For example, you can set a matrix value
outside the diagonal to zero by copying the diagonal, setting all matrix values to zero and
reinserting the diagonal (see User Manual, Chpt. 3.4.5, page 869).
The function offers the option of setting the values of the diagonal with a new value, with the
matrix values remaining unchanged for all relations FromZoneNo ToZoneNo.

3.3.6

Round
With the Round function you round all matrix values to a specified precision. The matrix values
are rounded up or down so that the new value is a multiple of the value rounded. Therefore, it
is possible to round up to 0.1 or 0.25, for example (see User Manual, Chpt. 3.5.1, page 875).

3.3.7

Form reciprocal, raise to power, take logarithm, exponential function


The Reciprocal function offers the possibility of transferring the reciprocal of any given matrix
value into the matrix (see User Manual, Chpt. 3.5.6, page 884).
The Raise to power function offers the possibility of giving an exponent for all matrix values and
transferring the result in each case as the new matrix value (see User Manual, Chpt. 3.5.7,
page 885).
The Take logarithm function offers the possibility of determining the logarithm for each matrix
value and transferring the result in each case as the new matrix value (see User Manual, Chpt.
3.5.8, page 887).
The Exponential function offers the possibility of using each matrix value as exponent for e (e
= 2.71828183) and transferring the result in each case as the new matrix value (see User
Manual, Chpt. 3.5.9, page 888).

3.3.8

Maximum or minimum formation


The formation of a maximum or minimum results from the comparison of each value in the
processed matrix with a user-defined value or the matrix value of the same relation in another
matrix (see User Manual, Chpt. 3.5.10, page 890) and (see User Manual, Chpt. 3.5.11,
page 891).
The result matrix then contains the following values for each relation.

PTV AG

The greater of the two values at maximum formation


The smaller of the two values at minimum formation

187

Chapter 3: Demand model

Maximum or minimum formation is mostly used for symmetrization of a matrix, often in


connection with Transposing (see "Transpose, reflect upper or lower triangle, apply mean
value" on page 186).

3.3.9

Make symmetrical: mean value upper / lower triangle


The Make symmetrical function calculates the mean value from the matrix values by element
in the upper and lower triangle and replaces them by this mean value (see User Manual, Chpt.
3.5.12, page 893).

3.3.10

Calculate the combination of matrices and vectors


Values which result from a combination of other matrices and vectors can be assigned to a
matrix. The values of individual input matrices and vectors can be transformed by element,
multiplied by a factor and then added (see User Manual, Chpt. 3.5.13.1, page 894).
Note: This function allows you to add exponential or Box-Cox transformed complex terms.

3.3.11

Defining matrices as formulas


Similar to formula attributes, matrices (see "Formula attributes" on page 104) can be defined
as formulas. Using a combination of matrix and vector expressions, you can define a term that
is automatically updated when changes are made to matrix data or zone attributes. This way,
the matrix is always displayed with its current values. The data in formula matrices is only
readable (see User Manual, Chpt. 3.3.4.2, page 834).

3.3.12

Projection
The functionality is primarily used if origin or destination total values of a zone are to be
multiplied by a particular value, or a particular expected value is to be attained, which can be
necessary in some circumstances after origin-destination studies. Matrices collected are often
just random samples and must be projected to census values.
Matrix values can be projected per row (singly constrained projection regarding the
generation), per column (singly constrained projection regarding the production) or by row and
column (doubly constrained projection) (see User Manual, Chpt. 3.5.14, page 896).
Singly constrained projection means that each row or column is multiplied by a fixed value.
This value can be a procedure parameter or for zone and main zone matrices an attribute
of the zone or main zone. The complexity of doubly constrained projection is illustrated in the
example below.
Objective: projection of origin and destination demand as follows:

188

zone 1 by 10 %
zone 2 by 20 %

PTV AG

Chapter 3.3: Displaying and editing matrices

Zone

Origin traffic

20

30

50

40

50

90

Destination traffic

60

80

140

Table 45: Basic matrix

Line by line multiplication, therefore for purely singly constrained projection of the demand
regarding production originating from zone 1 by 10% and zone 2 by 20%, produces the
following matrix.
Zone

Origin traffic

22

33

55

48

60

108

Destination traffic

70

93

163

While the origin traffic has been increased correctly, the destination traffic has not.
For the doubly-constrained projection, the Matrix editor uses an iterative process, also called a
Multi-procedure. In an iterative progression, this process searches for the solution that best
achieves the expected values (see "The multi-procedure according to Lohse (Schnabel 1980)"
on page 189).
The Matrix Editor thus provides the following solution which correctly projects the origin and
destination traffic.
Zone

Origin traffic

21

34

55

45

62

107

Destination traffic

66

96

162

Table 46: Result matrix

The multi-procedure according to Lohse (Schnabel 1980)


With the multi-procedure new traffic flows are calculated in each iteration step Fij (Schnabel
1980).
The iteration formula applied is as follows

Fij(n+1) = Fij(n) qi(n) zj(n) f(n)


with

Q ip
q i ( n ) = -------------------------------Z jp
j Fij -----------Zj ( n )

PTV AG

189

Chapter 3: Demand model

Z jp
z i ( n ) = --------------------------------Q ip
i Fij ------------Qi ( n )
Gp
f ( n ) = ----------G(n)
Qip

Desired origin traffic zone i

Zjp

Desired destination traffic zone j

Gp

Desired total traffic

Fij(n)

Traffic flow from zone i to zone j in iteration n

Qi(n)

Origin traffic zone i, iteration n

Zj(n)

Destination traffic zone j, iteration n

G(n)

Total traffic, iteration n

This iterative calculation is done repeatedly until the following conditions are met for all
boundary values (origin and destination expected values).

Qi ( n )
-------------- 1 for all zones i
Q ip
Zj ( n )
------------- 1 for all zones j
Z jp
The threshold suggested by Lohse was used. It states that
1
1
= ----------------------------- or = ---------------------------( QF Q ip )
( QF Z jp )

QF: quality factor

3.3.13

Projection of aggregated areas


You can also use this function for matrix projection. Contrary to simple projection, you do not
specify a factor per row or column, but the rows and columns of matrices are separated into
groups. You then define a projection factor per group or per relation between the groups (see
User Manual, Chpt. 3.5.15, page 900).
Thereby you need to distinguish between two modes:

Singly constrained projection by territory: This largely corresponds to singly


constrained projection (see "Projection" on page 188). The only difference is that for
projection by territory the rows or columns of the matrix are separated into groups ("areas")
and you specify a projection factor per group.
Projection by item: For this procedure the projection factors are not defined per row or
column, but per row/column relation. Here the rows and columns are also separated into
groups and you specify a projection factor per "group relation".

If you are using a matrix with network references, i.e. a zone or a main zone matrix, you can
choose an attribute of the zone or main zone to separate the rows and/or columns into groups.

190

PTV AG

Chapter 3.3: Displaying and editing matrices

If in this case, you e.g. select the attribute Main zone number for a zone matrix, singly
constrained projection will use a specific factor per main zone for projection. Projection by item
would use a different factor per main zone relation.
Note: The term "territory" used here merely describes a group of rows or columns and is not
to be confused with the network object of the same name.

3.3.14

Converting zone and main zone matrix into each other


When calculating the main zone matrix from a zone matrix, you add the matrix values of zones
that belong to the same main zone. This applies both to OD demand and skim matrices. The
total amount of the matrix values are added to the main zone matrix, the zone matrix is kept.
When disaggregating a main zone matrix you divide the matrix values of the main zones into
several matrix values for the individual zones and add them to a zone matrix. The values can
be equally distributed. However, you can also weight them. As weighting factors you can use
the values of one or two zone matrices or of OD zone attributes.
If you select two weighting factors, the new matrix values are calculated as follows:
(1)

b ij

(2)

w ij w ij
= ------------------------------------------------------------------------------------------------- a IJ
(1)
(2)
w kl w kl

k Index ( I )

l Index ( J )

whereby

i, j
i, j
Index(I), Index (J)
bij

Zone indices

aij

Value in input matrix (main zone matrix)

wij(1), wij(2)

two weighting factors

Main zone indices related to the zone indices


Number of zone indices belonging to the main zone
Value in the output matrix (zone matrix)

Note: If the denominator of a fraction is zero, weighting will be ignored.

Use case
You would like to correct a matrix or adjust it using count data. The count data available refers
to a rougher zone structure than your network. In this case, you first aggregate the zone
matrices, then perform a correction procedure (e.g. TFlowFuzzy) and finally disaggregate the
matrix again.

3.3.15

Extending matrices
You can extend external matrices during an arithmetic operation, i.e. you can add columns and
rows. To do so, choose an arithmetic operation that allows you to combine external matrices
with matrices that have different OD pairs.
You can use any arithmetic operation that requires a second operand, e.g. the basic ones or
forming the maximum or minimum.
The matrix data is calculated as follows:

PTV AG

191

Chapter 3: Demand model

The arithmetic operation is performed for the OD pairs that occur in all matrices.
If an OD pair is not listed in all matrices, a null is entered for it before the arithmetic
operation is performed. Then the arithmetic operation is performed.
For OD pairs that are not listed in any of the matrices, a default value is set in the results
matrix.

Example of extending a matrix


On the addition, the two matrices are extended. The standard value specified for new OD pairs
is 99.

Matrix in Matrix editor window


1

Matrix chosen as operand

3.3.16

Matrix extended on addition


1

99

99

99

99

Aggregating matrix objects


This function allows you to group several matrix objects to create one or several new objects.
You can use the Aggregate function to rename zones and/or group them into larger units (e.g.
districts). The number of rows and columns of a matrix is changed through aggregation.
The new matrix values are calculated with the aid of the following formulas:
Arithmetic mean

i = 0 qi

--------------------n

192

PTV AG

Chapter 3.3: Displaying and editing matrices

Weighted mean

i = 0 qi gi

-----------------------------n

i = 0 gi
with

qi

Matrix value of ith zone

gi

Weighting of ith zone

Number of columns or rows

Example of aggregating matrix objects


The matrix values of the matrix below are aggregated.

Zone allocations and settings:

Zone 10 is removed from the matrix


Zones 20 and 30 are aggregated and will form the new zone 39
The weighted mean is used as aggregation function.
The matrix data is weighted using the following matrix.

Origin and destination zones of the matrix are aggregated


The matrix values of the original matrix are used

The following matrix results.

Matrix values of destination zone 39 were calculated as follows:


6 6 + 7 7 + 1 10 + 1 11- = 7.1
--------------------------------------------------------------------6+7+1+1
14
2 + 15 2- = 14.5
---------------------------------2+2

PTV AG

193

Chapter 3: Demand model

3.3.17

Splitting (extending) matrix objects


Using the Split function, you can subdivide zones into smaller units. The number of rows and
columns of a matrix is changed through splitting. This function is often used for adapting overall
demand matrices to a finer zone classification in the network model.

If you only specify one factor for an object generated during splitting, this factor applies to
both the source and destination traffic in the demand matrix.
If origin and destination value are to be distributed with different proportions in a zone
generated by splitting, a destination traffic factor must also be specified after the origin
traffic factor.

For a demand matrix, the matrix value is generally distributed across the zones (1.0 = 100 %)
created through splitting. When choosing the splitting factors for zone generation, you can
decide whether or not you want to include the expected gains (total > 1.0) or losses (total < 1.0)
per split zone.
For a skim matrix, the matrix value per split zone is generally assigned to the new zones using
the factor 1.0, i.e. they remain unchanged.

Example of splitting matrix objects


The zones of the following matrices are split and deleted.

Thereby the following settings are made:


Zone number old

Zone number new

Factor origin traffic

Factor destination traffic

100

1,001

0.3

0.1

100

1,002

0.5

0.2

100

1,003

0.2

0.7

200

2,001

0.7

0.7

200

2,002

0.3

0.3

In addition, all trips created within the cell are set to null.
This produces the following matrix:

Total of matrix data for all OD pairs from/to 1,001..1.,003 equals 1,000.

194

PTV AG

Chapter 3.4: Matrix correction

3.4

Matrix correction
You have different possibilities of correcting the demand matrix values with count data.

3.4.1

Updating demand matrix with TFlowFuzzy


Projecting PrT path volumes
Calibrating a PrT matrix

Updating demand matrix with TFlowFuzzy


Like all matrix correction procedures, TFlowFuzzy is meant to adjust a demand matrix, so that
its assignment results for a supply actually match the real supply observed (source/target
traffic, passenger trips unlinked or number of boarding/alighting passengers). This procedure
can be useful in several situations:

A demand matrix based on empirical survey data is outdated and you want to update it
without having to conduct a new (origin-destination) survey. The update shall be based on
based on census data only.
A matrix generated from the transport network model is to be calibrated, therefore counted
volume data are to be used.
A matrix generated from incomplete or not reliable data is to be improved by more
comprehensive/reliable volume data counted simultaneously.
A survey contains the journey distance distribution, but the model does not reflect the data
with the level of accuracy required.

TFlowFuzzy will solve this problem for PuT as well as for PrT. The update only affects the
demand matrix - not the time series - and always refers to total volumes (instead of volumes
per time interval).
The flow of information always follows the given order.
Old
matrix
data

New
count
data

TFlowFuzzy

New
matrix

The workflow for the matrix calibration is as follows.

PTV AG

195

Chapter 3: Demand model

Count data
Network
model
Assignment

TFlowFuzzy

Demand
matrix

You can choose the following count data:

Link volumes
Origin/destination travel demand per zone
Volumes of turns at nodes and main turns at main nodes (as long as they are defined)
Volumes via screen lines
Volumes on lanes
PuT passenger trips unlinked per line
PuT passenger kilometers per line
Boarding/alighting passengers at stop areas
Skim data distribution, e.g. journey distance distribution

You can also combine count data.


A detailed example of how to use journey distance distribution is available in the folder:
...\Users\Public\Public documents\PTV Vision\PTV Visum13\Training\TFlowFuzzy.
It is best to work with volumes on lanes if you want to use count data that comes from stop line
detectors. These are - other than manually collected node flows - not already assigned to a
(main) turn, but to the lane the detector is located on. If you are using lane counts, you need to
model the lane allocation at the respective node in the Junction editor. Visum aggregates lane
counts to counts per lane group, i.e. the count data is added across all (main) turns that have
at least one shared lane. TFlowFuzzy compares the count data sums to the volumes of all
routes that use this lane group.
Sometimes PuT passengers alighting/boarding at stop areas are counted separately for each
direction. To be able to use the information content of the disaggregated count data, without
having to separate the stop area into several parts, separate the line routes traversing the stop
area into groups. Then specify count data and tolerances for each group.
For the update, the specified count values are compared with the volumes, which result from a
pre-calculated assignment of the previous demand matrix. Differences between count values
and volumes are balanced by adjustment of the demand matrix for the assigned demand
segment. The simplest case refers to a single demand segment. The volumes from the

196

PTV AG

Chapter 3.4: Matrix correction

selected network object are then taken from the assignment result of this demand result, and
the count values also only refer to this demand segment. TFlowFuzzy can also simultaneously
update the demand matrices of several demand segments, if only total count values are
specified for all demand segments. Then the count data specified is distributed proportionally
to the respective demand segment share of the assignment volumes. The demand matrix for
each demand segment is then updated individually.
Compared to other procedures, the outstanding quality of TFlowFuzzy is

that you can combine the following for matrix correction: origin/destination traffic, link
volumes, turns, main turns or screen lines, passenger trips unlinked and passengers
boarding/alighting at stop areas and distributions (e.g. journey distance).
Count values do not have to be available for all network objects.
The statistical uncertainty of the count figures can be modeled explicitly.
You can specify that the distribution of the result matrix must correspond to the distribution
of an existing demand matrix.
You can use count data that only covers part of the PuT lines. In this case, only volumes or
boarding/alighting passengers that refer to active line route elements are taken into
account for calculation.

3.4.1.1

Methodological basics of TFlowFuzzy

Since the eighties, primarily in English-speaking countries, so-called matrix correction (or
matrix update) techniques have been used to produce a current demand matrix from an earlier
travel demand matrix (base matrix) using current traffic count values. Based on research by
Van Zuyten/Willumsen (1980), Bosserhoff (1985) and Rosinowski (1994) which focuses on
matrices for private transport, PTV has extended the application of these techniques to public
transport.
The starting point for the classic procedure is the travel demand for the individual OD pairs fij.
Travel demand is usually described as a matrix, but for our purposes a vector representation
containing all non-zero OD trips is more suitable.

0
f 21
f 31

f n1

f12
0
f32

f n2

f13
f 23
0

f n3

f1n

f 2 n
f 3n =

0

f12
f13

f1n
f 21
f 23


f 2n
f 31

While it is usually assumed, that a matrix based on an earlier time is known, only partial
information is provided for the current state. Important is the situation where there are no data
based on relations (from an origin destination survey) available, but only count values at
individual positions in the network. These can be both origin / destination traffic as well as link
volumes. We note the count values as another vector.
v r = (v1 v2
PTV AG

v3 vm )
197

Chapter 3: Demand model

The trips of any OD pair provides a certain share to each traffic count. In case of boarding and
alighting passengers the marginal sums of the demand matrix are known. In case of link counts
the counted volumes correspond to the sum of all (proportional) OD trips traveling on this link.
In general there is a linear relation between the demand on the OD pairs and the traffic counts.
Af=v

whereby A is called flow matrix. ask is "the share of passengers on movement k, traversing link
s". For origin / destination traffic count values, A is especially constant, as specified with
example n = 3, m = 6.
1

0
0

1
0

1 0 0 0 0 t12 board1

0 1 1 0 0 t13 board 2
0 0 0 1 1 t21 board3

=
0 1 0 1 0 t23 alight1

0 0 0 0 1 t31 alight2
1 0 1 0 0 t32 alight3

In this case, A does not depend on the timetable. However, the supply dependent trip choice
flows into A for link volumes; the flow matrix is obtained for example, through assignment of
any matrix (for example the old demand matrix) on the supply at the time of the count. Both
types of count values can be also be used next to each other without a problem.
A problem for the matrix correction is that, usually m << n2 and therefore the new matrix is
underdetermined by the count values. Out of the countless matrices which match the count
values "match", only the best is selected according to a evaluation function q, thus solves
max q(f), so that A f = v
A combination of entropy and weighting with the proportions of the old matrix usually serves as
an evaluation function; q is usually non-linear, which is why the problem is solved iteratively (for
example with Newton's method).
In this wording of the matrix correction problem there is, however, another weakness of the
classic approach: vector v of the count values is assumed as a known parameter, free of every
uncertainty. A q maximum is only selected from the matrices which fulfill the exact secondary
conditions. The count values thus receive an inadequate weight, because each survey
provides a snap shot, which is afflicted with a statistical uncertainty. Conventional procedures
(for example from Willumsen) do not allow such a state, because the boundary sums are
perceived as "strict" secondary conditions.
PTV has therefore taken on the approach by Rosinowski (1994), who modeled the count
values as fuzzy measured data according to the Fuzzy Sets Theory. If it is known that in a
zone, the origin traffic fluctuates up to 20 % from day to day, in other zones however about
25 %, this is illustrated with the respective bandwidths. In the secondary conditions of the
matrix estimation problem, there are thus Fuzzy Sets ~
v s with sets of variables of different
widths which replace strict values.
max q(f), so that A f = v

198

PTV AG

Chapter 3.4: Matrix correction

The illustration of Fuzzy Sets compared to pure limits allows the preference of central values
to be expressed within the set of variables. This means, that values close to the mean values
are generally preferred, but values within the margin are also accepted, if this means that a
much better q value is achieved.
How can the Fuzzy Sets now be treated numerically for the solution of the optimization
problem? The obvious trip is, to include the membership function of the individual Fuzzy Sets
in the evaluation function and in comparison weighted appropriately. To be able to continue
using standard procedures of non-linear optimization, the resulting objective function must also
be twice continuously differentiable, producing restrictions regarding the form of membership
functions. Especially the usually partial linear triangles or trapezoids are eliminated. Instead we
use the same mechanism as for the weighting with the original matrix, to support the choice of
central values from the set of values. As a comparison, here the evaluation function of the
weighted entropy maximization.

q( f ) =

n n

f ij

f ij ln f ij
f ij
i =1 j =1

If f ij is already set as a demand from the original matrix, the maximization of q benefits
matrices which slightly differ from the original matrix. This principle can be transferred to our
new optimization problem:
max q(f, s, s), so that
Af+s=v
A f - s = v
s0
s 0

where v ,v = maximum or minimum of the set of variables of the Fuzzy Sets.


If the slack variable s, s is included in the weighted entropy maximization s = s = 0 , matrices
are favored that fulfill A f = v "best". Doubling the equation appears to be a disadvantage,
because this has a direct effect on the calculation time of the runtime determining Gauss
method within the Newton iteration. Symmetries in the resulting equation system however, still
only allow to solve a system half the size and hence, deduct a solution of the entire system.
The range of solutions of the estimate problem increases due to the Fuzzy formulation and
therefore the degree of freedom for the evaluation (here: entropy maximization), so that
generally higher target function values can be achieved. To make it clearer, the "most likely"
demand matrix is thus estimated, which represents the count values within the bandwidths.

Illustration of Fuzzy sets with an example


A Fuzzy set is generally defined as a set of possible values (set of variables) and a
membership function with values between 0 and 1, which specifies "how much an element of
the set of values is perceived as related to the fuzzy set". If the membership function is 0, the
element does not belong to the unclear set. For a value of 1, element "total" belongs to the set
and interim values express the quality of approximation. If for example, you want to express the
value "approximately 4" as a fuzzy set, the set of variables could contain the interval [3;5] and
the membership function rises from value 0 to the interval margins to a maximum of 4.
PTV AG

199

Chapter 3: Demand model

Membership
function

0
3

To make bandwidth modeling in TFlowFuzzy more manageable and operation easier, it is


assumed that the membership function has a very special form. From value 1, which is
assumed by the survey count values, it drops symmetrically to both sides. It thus creates a
triangle, which is determined through the following values.

Membership
function

0
z-*s

z
s

z+*s

the count value itself, where the membership function assumes its maximum
the distance between the count value, where the membership function drops to value 0
a predefined scaling factor ( > 0)

Values z, s and are entries for TFlowFuzzy (see User Manual, Chpt. 3.7.1, page 910). z and
s are specified individually for each count value (link volume, origin / destination traffic, turn
volume or main turn volume, as long as a main node is defined), whereas is a global
parameter for the procedure.

3.4.1.2

Numeric example for TFlowFuzzy

A calculation example is used to illustrate the matrix correction procedure. A PuT service is
defined in the very simple network with four zones shown here.

200

PTV AG

Chapter 3.4: Matrix correction

The link bars show the assignment result for the following matrix, which we assume were
obtained a long time ago by means of a passenger survey:
$VR
* PTV
* Time interval
0.00
24.00
* Factor
1
* Mode of transport No. 3
*
3 Mode of transport PuT
*
4 Mode of transport PrT
* Number of zones
4
1
2
3
*Zone
1
Total =
0
100
100
*Zone
2
Total =
100
0
100
*Zone
3
Total =
100
100
0
*Zone
4
Total =
100
100
100

4
300
100
300
100
300
100
300
0

Counts have since been completed on all links of the network, and the following volumes
obtained.

The counted values for this example are based on the assumption that the demand matrix has
since changed as follows.
$VR
* PTV
* Time interval
0.00
24.00

PTV AG

201

Chapter 3: Demand model

Factor
1

* Mode of transport No. 3


*
3 Mode of transport PuT
*
4 Mode of transport PrT
* Number of zones
4
1
2
3
*Zone
1
Total =
0
150
100
*Zone
2
Total =
150
0
100
*Zone
3
Total =
100
100
0
*Zone
4
Total =
100
80
100

4
350
100
330
80
300
100
280
0

The counted values from the figure are loaded into Visum LinkAddValues. Additionally, for
each individual counted value or collectively, a random sample fuzzy value can be added,
which means a bandwidth, within which the counted values actually fluctuate from one survey
date to another. This fuzzy value can be accepted as it is or obtained empirically by counting
the same OD relations on different dates.
TFlowFuzzy now calculates a new matrix, which on the one hand exhibits to a very high degree
similar ratios between the number of trips in the individual OD relations as in the old matrix (by
maximizing the weighted entropy), and on the other hand, during assignment matches the
counted values from the new survey within the specified bandwidth.
In the above example TFlowFuzzy, with a random sample accuracy of 5 %, calculates the
following matrix, which matches the assumed "ideal solution" very well.
$VN
4
*
*

1
346
1:
2:

3:

4:

3
298

4
281

148

99

99

100

83

100

99

83

99

346
0

2
331
331

148
298
99
281
99
* 1256

3.4.2

Projecting PrT path volumes


The Projection of routes command adjusts the demand matrix of a PrT transport system to the
counted data of particular links. Thereby all movements Fij that use a selected link for a PrT
demand segment are projected, so that the link volume corresponds to the count data
(AddValue). The relations used in this process are the result of an assignment in which all used
trips are saved along with their volumes.
The update only affects the demand matrix - not the time series - and always refers to total
volumes (instead of loads per analysis time interval).

202

PTV AG

Chapter 3.4: Matrix correction

3.4.3

Calibrating a PrT matrix


The Cali procedure provides a calibration function that uses count data to calculate projection
factors - based on assignment results - for origin and destination sums of a PrT demand matrix.
Using a balancing procedure the matrix is then projected to the sum values.

3.4.3.1

General principle of the calculation procedure

The projection of the matrix corresponds to the Increase factor model with justification, known
in traffic planning. By comparing the calculated volume with the count data, the counted cross
sections supply information on "adjustment factors" which need to be taken into account. Here
it has to be taken into account that an origin/destination relation can traverse several counted
cross sections, that is, it might be influenced by several adjustment factors.
The calculation process has two stages.
1. Determination of the adjustment factors
First, the calibration function calculates an adjustment factor ki for each count value zi.

These apply to all relevant flow bundles.


This results in modification potentials for all relevant origin and destination traffic.
Since the adjustment factors belonging to a zone might have to be calculated using
different count value adjustment factors zi..n, these factors must be averaged and
balanced.
Adjustment factors for origin and destination traffic are thus generated for those origins
(rows) and destinations (columns) which were found by flow bundles.
Rows and columns which were not found by flow bundles are assigned a mean
adjustment factor determined by the adjustment factors for traffic flow elements.
2. Projection of the matrix using the projection factors generated as explained above

3.4.3.2

Example: Matrix projection

The Fij matrix of the last assignment serves as the basic matrix.
Zone

Origin traffic

20

30

50

40

50

90

Destination traffic

60

80

140

If the traffic of Zone 1 is to be increased by 10 % and the traffic of Zone 2 by 20 %, the following
matrix (for a projection of the origin only) will result:

PTV AG

Zone

Origin traffic

22

33

55

48

60

108

Destination traffic

70

93

163

203

Chapter 3: Demand model

It is clear that, although the origin traffic increased by the required amount, the destination
traffic did not, because
1.1 * 60 = 66 and 1.2 * 80 = 96.
This is why an iterative procedure, the Multi-procedure according to Lohse (Schnabel 1980), is
used for origin and destination projection, as in an iterative process it searches for that one
solution that is best used to reach the target values (see "The multi-procedure according to
Lohse (Schnabel 1980)" on page 189).
For the above example the following solution is found:

204

Zone

Origin traffic

21

34

55

45

62

107

Destination traffic

66

96

162

PTV AG

Impact models
An impact model contains all methods to calculate the impact of traffic. It calculates results on
the basis of data and thus represents the computation kernel of the application. Components
of the different impact models offered in Visum are in particular assignment, skim calculation,
line blocking, line costing calculation (PuT operating indicators) and emission calculation,
including the impedance models used in them. Each of these methods is part of at least one of
the impact models for users, operators and the environment.

Subjects

4.1

The types of impact models


Impedance functions
Paths in PrT and PuT
Skims / indicators

The types of impact models


A transport supply system has diverse impacts which may vary because of measures. Impacts
always refer to those actively or passively involved in traffic, for example the users or operators
of the transport supply system, to the general public or the environment. The impact models in
Visum are differentiated according to those involved and each comprises all methods on
calculating the effects on one of the roles mentioned.

4.1.1

The user model


Users of infrastructure for private transport are mostly car drivers and their passengers, but
also non-motorized travelers such as cyclists and pedestrians. Users of public transport are
public transport passengers. Objective of the user model is to determine the impacts of a
transport supply system on travelers. Important skim data for evaluating the transport supply
are the journey time and traveling expenses between two zones. To evaluate a public transport
supply, additional skim data such as number of transfers, transfer wait time and service
frequency must be considered.
To determine these user-specific skims, the OD trips of travelers are modeled. A user chooses
a route for his trip which appears convenient to him. If in addition to the route, the user also
selects the departure time of his trip, one speaks of a connection independent of the mode. In
addition to the spatial course, a connection thus comprises the entire temporal course: In
public transport especially the departure and arrival times at the boarding stop, at the transfer
stops and at the destination stop and in private transport the selected departure time, the
arrival time and the transit time for each location along the route. If the temporal progression of
the traffic situation has been explicitly modeled in this way, one speaks of a dynamic model
(dynamic assignment). There is no time axis for a static model, however, so that OD trips take
place without temporal course and have a simultaneous effect on each location in the network.
There are static and dynamic user impact models in both PrT and PuT.

PTV AG

205

Chapter 4: Impact models

Methods to model the travel behavior are based upon search algorithms which determine
routes or connections between an origin and a destination. Procedures used as search
algorithms are those which determine the best, meaning those which determine paths with the
lowest impedance or a set of sufficient paths. Impedance can consist of times, distances, and
costs. Depending on the search algorithm used, the paths found represent routes or
connections. The trips by OD pair are distributed among the paths found. This combination of
path search and trip distribution is called assignment. Private transport assignment assigns
vehicle trips; public transport assignment assigns passenger trips.
For every route or connection between two zones skims can be calculated which describe the
service quality of the route/connection. In addition to this, an assignment produces traffic
volumes for links and turns, and in PuT projects also for stops and stop points plus all objects
of the PuT line hierarchy from the transport system down to the level of individual vehicle
journeys. In contrast to a quality skim such as, for example, journey time, the volume is only an
indirect skim which by itself is not suited for evaluating the transport supply system. The
volume is rather used to deduce

saturation of PuT lines which affects the comfort of passengers and the revenues of
operators
noise and pollution emissions which indicate the environmental impact

Thus, the volume resulting from the user impact model serves as a basis for the procedures
provided by the operator impact model and those of the environmental impact model as well.
Visum offers various assignment procedures for private and public transport. They differ by the
search algorithm and by the procedure used for distributing demand. These assignment
procedures are a central part of Visum. There are PrT models and PuT models.

4.1.2

PrT (see "User model PrT" on page 211)


PuT (see "User model PuT" on page 429)

The operator model


Transport supply operators are PuT transport companies and transport associations, in a
broader sense these also include the PuT contractors of the operators. To offer public transport
service, PuT operators develop line networks and timetables from which the user can then
choose connections.
To estimate the impacts on PuT operators, the so-called operator model is used to determine
indicators which describe the operational and financial requirements for offering public
transport supply on the one hand and on the other hand the expected revenues (see "Operator
model PuT" on page 521). The PuT operator model comprises the following methods.

Line blocking which determines the number of required vehicles


Determining operational costs
Estimating revenues
Line costing which distributes the operational costs and revenues over PuT lines

Compared to the PuT, the PrT network is generally operated by the state, countries or councils,
but also more and more by private investors. Decisions are geared towards the impact on the
general public, rather than on the impacts on the operators themselves, which is why in general
a different operator model has to be used for PrT. Here the economical analysis (EWS) impact
model is available in Visum. This model comprises methods on economical return of

206

PTV AG

Chapter 4.2: Impedance functions

investment analysis according to recommendations for economic feasibility studies published


by the German FGSV (Road Traffic Research Association in Germany in 1997) (see
"Economic assessment according to EWS" on page 663).

4.1.3

The environmental impact model


Visum provides three models within the environmental impact model, to calculate the
environmental impacts which are noise and pollution emissions, caused by motorized private
transport (see "Environmental impact model and HBEFA" on page 651).

4.2

Noise-Emis-Rls90: Calculation of noise emission levels in accordance with the guideline


on noise reduction for roads, edition 1990 (RLS-90), without considering immission
parameters.
Noise-Emis-Nordic: Calculation of noise emission levels in accordance with Nordic Council of Ministers (1996).
Pollution-Emis: Calculation of air pollution emissions in accordance with emission factors
of the Swiss Federal Office for the Environment (BAFU).

Impedance functions
An impedance function generally measures the effort connected to a traffic process. All
instances are summarized to this effort, which prevent participants from carrying out this
process and therefore create an impedance. Effort examples are especially time and costs
connected to the process. You can also enter subjective criteria in the impedance. Thus, the
impedance of a certain connection in the PuT may increase, if certain comfort criteria are not
satisfied.
Impedance functions play an important role in several impact models. In the assignment, the
impedance function assigns a route or connection an effort. In PrT, especially the journey time
in the loaded network flows into the impedance, but it can also be additional properties such as
traveling expenses and possible toll. For dynamic assignments, it is also the discrepancy
between the departure time and the desired departure time. In PuT, in addition to the travel
time, it is mainly the number of transfers and the fare which have an effect on the impedance.
A problem for impedance functions is that completely different aspects are included and have
to finally arise from conjoint evaluation in form of a number. These different aspects which are
partially measured in different units, must therefore be recalculated and weighted against each
other. In general, weighting of the factors for different groups of assessing personnel is
different. For this reason, impedance functions for example can be defined at the assignment
per demand segment (see User Manual, Chpt. 5.2, page 977) and at line blocking per vehicle
combination (see User Manual, Chpt. 7.1.3.2, page 1169).
In Visum, impedance functions are used in the following contexts:

PTV AG

Assignment (User model): The impedance function assigns the effort to each path, thus
depending on the type of assignment, each route or connection, which the passenger has
to make, if he decides to take this path. The most natural criterion is the travel time which
has the corresponding unit time [s]. Especially in PrT, the travel time of a link is not
constant, but depends on the volume, the coherence is described in a VD function.

207

Chapter 4: Impact models

Demand models (User model): Within the framework of trip distribution, mode choice, as
well as combined procedures for trip distribution and mode choice, the impedance function
allocates an OD pair or the mode choice for this relation to the effort, which has to be
overcome for this choice. In this context we are traditionally talking about utility functions.
Although the supporting concept is identical, the benefit of it is, however, only the negative
impedance of the process.
Line blocking (Operator model): The impedance function assigns each activity (vehicle
journey, empty trip, layover, etc.) in a cycle the effort which arises, if the activity is
performed by this cycle. The most natural criteria here are the costs.

Despite these different application areas, the impedance function structure is always the same:
Each impedance function consists of a sum, in which each summand evaluates a certain
aspect of the effort and is weighted by a coefficient (see illustration 56). To calculate the
impedance of a traffic process, the properties of the process are first determined regarding
each aspect. Each aspect is then evaluated separately, in PrT especially by evaluating the VD
function. This evaluation of individual aspects is then provided and summed up with the
weighting factors.

Illustration 56: Impedance calculation for a PuT connection, for clarity illustrated in the unit [min]

208

PTV AG

Chapter 4.3: Paths in PrT and PuT

4.3

Paths in PrT and PuT


All assignments in Visum in PrT as well as in PuT are path-based, meaning that possible paths
are calculated for each OD pair and loaded with a demand share. All other results, especially
the different network object volumes and the skim matrices are derived from these loaded
paths. These paths are saved with the assignment result and can be analyzed after the
assignment for flow bundle calculation, for example.
A path first describes the exact local course of a translocation in the network model, which
means, that all traversed network objects such as nodes, links, turns, main nodes,
connections, if applicable also stops, line routes and time profiles are known. If the departure
time and thus the temporal course is added to the spatial course, we are taking about a
connection, otherwise a route. For PuT paths, in addition to departure time for a connection
compared to the route, the information on used vehicle journeys is included.
If an assignment produces routes or connections depends on the type of assignment. Dynamic
PrT assignments and the timetable-based PuT assignment create connections, static PrT
assignments as well as the headway-based PuT assignment calculate routes. In principle, the
user can select, whether internally calculated connections should be saved as such or only as
routes, or not at all respectively for PrT (see User Manual, Chpt. 5.1.2, page 975) and PuT
(see User Manual, Chpt. 6.1.1.2, page 1072). If you do not save the connections, less memory
is required, however, posterior analyses of the connections are no longer possible, even if a
dynamic assignment procedure was applied. Network volumes are still calculated and can
even be output differentiated according to analysis time intervals.

4.4

Skims / indicators
A skim is a measurement taken from the traffic model. Typical examples are the mean travel
time from a zone A to a zone B, which is calculated from the travel times of all paths found, as
well as the total PuT journey time, which is the sum of the journey times of all PuT passengers.
Skims can be divided into global skims, which describe properties of the entire traffic model,
and into skims gained per OD pair. The latter are stored in skim matrices, whereby the entry xij
for the skim value, refers to the relation from zone i to zone j.
Generally, skims measure the properties of the traffic model. In feed back models they are also
the input data for the demand modeling procedures, especially for trip distribution and mode
choice.

4.4.1

Skim matrices
Skim matrices describe properties of each relation from an origin zone A to a destination zone
B in the traffic model. Each individual skim (for example the travel time in a vehicle) is extracted
from the path properties from A to B, which belong to a demand segment. The skim data is then
aggregated with the relative share of demand, which the path would attract, to a skim value for
the OD pair. This also applies, if there is no demand for the relation from A to B, because
distribution does not depend on the demand.

PTV AG

209

Chapter 4: Impact models

The calculation of skim matrices differs between PrT and PuT on some points. The calculation
of PrT skim matrices is either based on present paths from a previously calculated assignment,
or for each OD pair the optimum path with regard to the impedance is determined (in the
possibly loaded network). Compared to an assignment, the network is not loaded in this case.
Because in this case there is only one path per relation, the skim value is extracted directly
from this path. If, however, paths from an assignment are used for skim matrix calculation, the
value of the minimum or maximum path impedance can be output as skim value, or the
weighted or unweighted mean value calculated from all paths by OD pair.
In PuT always more than one route or connection is calculated per OD pair, and the skim value
is derived from these. In addition to the average determination, optionally weighted with the
demand share, the output of properties of the path with the least perceived journey time (PJT,
timetable-based procedure) or with the least impedance (headway-based procedure) as well
as quantiles are available as additional aggregate functions. The skim is especially directly
dependent on the applied search strategy. Because not only the saved, but all paths found are
included in skim matrix calculation, the result differs from the result subsequently derived from
the paths. This is the case, if the demand becomes zero on some paths by an explicitly
requested rounding and the path is therefore not saved, but used for skim matrix calculation. If
demand and volume rounding is switched off, such differences cannot occur.

4.4.2

Global indicators
In addition to the skims by OD pair and demand segment, which are available in skim matrices
and are only calculated on demand, Visum automatically calculates a specified set of global
indicators with each assignment. These are properties of the overall assignment result, i.e., of
the traffic model itself. Typical values are the mean travel time in the network, the total vehicle
impedance in PrT, the total journey time of all PuT passengers, as well as the number of
passenger trips by PuT line. The global values are displayed via lists (see "Evaluation lists" on
page 731).
If several assignments are carried out subsequently, the global values represent the properties
of all paths in these assignment results. Compared to the skim matrices, these values orientate
themselves towards the loaded paths contained in the result. They are thus consistent with
properties of the saved paths.

210

PTV AG

User model PrT


The User model PrT calculates the effect of the private transport supply on all car drivers and
passengers, but also on non-motorized road users such as cyclists and pedestrians.

Subjects

5.1

Overview of the PrT assignment procedures


Example network for the PrT assignment procedures
PrT Paths
Impedance and VD functions
Impedances at node
PrT skims
Distribution of the traffic demand to PrT connectors
Blocking back model
Convergence criteria of the assignment quality
Distribution models in the assignment
Incremental assignment
Equilibrium assignment
Linear User Cost Equilibrium (LUCE)
Equilibrium_Lohse
Assignment with ICA
Stochastic assignment
TRIBUT
Dynamic User Equilibrium (DUE)
Dynamic stochastic assignment
NCHRP 255
Assignment analysis PrT

Overview of the PrT assignment procedures


Visum provides several assignment procedures for the PrT. There are static assignment
procedures without explicit time modeling as well as procedures which use a time dynamic
traffic flow model.

PTV AG

The Incremental assignment divides the demand matrix on a percentage basis into
several partial matrices. Then, these partial matrices are successively assigned to the
network. The route search considers the impedance which results from the traffic volume
of the previous step (see "Incremental assignment" on page 315).

211

Chapter 5: User model PrT

212

Equilibrium assignment distributes the demand according to Wardrop's first principle:


"Every road user selects his route in such a way that the travel time on all alternative routes
is the same, and that switching to a different route would increase personal travel time."
The state of equilibrium is reached through a multi-step iteration process based on an
incremental assignment as the starting point. In the inner iteration step, two routes of a
relation are brought into a state of equilibrium by shifting vehicles. The outer iteration step
checks if new routes with lower impedance can be found as a result of the current network
state (see "Equilibrium assignment" on page 320).
The Equilibrium assignment LUCE uses the LUCE algorithm, which was conceived by
Guido Gentile. He collaborated with PTV to produce a practical implementation of the
method in Visum. Exploiting the inexpensive information provided by the derivatives of the
arc costs with respect to arc flows, LUCE achieves a very high convergence speed, while
it assigns the demand flow of each OD pair on several paths at once (see "Linear User Cost
Equilibrium (LUCE)" on page 331).
The Equilibrium_Lohse assignment models the "learning process" of road-users in the
network. Starting with an "all or nothing assignment", drivers consecutively include
information gained during their last journey for the next route search (see
"Equilibrium_Lohse" on page 346).
The Assignment with ICA brings the impedances at junctions into focus. It explicitly
regards lane allocations and further details. Especially the interdependencies between the
individual turns at a node are considered. With other assignment procedures, the detailed
consideration of node impedances usually leads to an unfavorable convergence behavior.
The assignment with ICA uses turn-specific volume-delay functions which are continuously
re-calibrated by means of the ICA. This leads to a significantly improved convergence
behavior (see "Assignment with ICA" on page 354).
The Stochastic assignment takes into account the fact that skims of individual routes
(journey time, distance, and costs) that are relevant for the route choice are perceived
subjectively by the road users, in some cases on the basis of incomplete information.
Additionally, the choice of route depends on the road user's individual preferences, which
are not shown in the model. In practice, the two effects combined result in routes being
chosen which, by strict application of Wardrop's first principle, would not be loaded,
because they are suboptimal in terms of the objective skims. In the Stochastic assignment,
an alternative quantity of routes is initially calculated, therefore, and the demand is
distributed across the alternatives on the basis of a distribution model (e.g. Logit) (see
"Stochastic assignment" on page 365).
The TRIBUT procedure, which was developed by the French research association
INRETS, is particularly suitable for modeling road tolls. Compared to the conventional
procedures which are based on a constant time value, TRIBUT uses a concurrent
distributed time value. A bicriterial multipath routing is applied for searching routes, which
takes the criteria time and costs into account. Road tolls are modeled as transport systemspecific road toll value, either for each Visum route or for link sequences between userdefined nodes (non-linear toll systems) (see "TRIBUT" on page 376).
In co-operation with the University of Rome, Visum provides the Dynamic User
Equilibrium (DUE). Additionally, the algorithm includes a blocking-back model, can regard
time-varying capacities as well as road tolls and provides a departure time choice model
(see "Dynamic User Equilibrium (DUE)" on page 389).

PTV AG

Chapter 5.2: Example network for the PrT assignment procedures

The Dynamic Stochastic assignment differs from all the previously named procedures as
a result of the explicit modeling of the time axis. The assignment period is divided into
individual time slices, with volume and impedance separated for each such time slice. For
each departure time interval, the demand is distributed across the available connections (=
route + departure time) based on an assignment model as in the case of the stochastic
assignment. With this modeling, temporary overload conditions in the network are
displayed, a varying choice of routes results in the course of the day, and possibly also a
shift of departure time with respect to the desired time (see "Dynamic stochastic
assignment" on page 419).

For each of the mentioned assignment procedures any number of demand matrices can be
selected for assignment.

One demand matrix of one PrT transport system, for example, a car demand matrix is
assigned.
Multiple demand matrices which contain the demand for one or multiple PrT transport
systems, for example, a car demand matrix and a HGV demand matrix are assigned
simultaneously.

Abbreviations which are used together with the User Model PrT, shows the table 47.
v0

Free flow speed [km/h]

t0

Free flow travel time [s]

vCur

Speed in loaded network [km/h]

tCur

Travel time in loaded network [s]

Impedance = f (tCur)

Volume of a network object [car units/time interval] = sum of volumes of all PrT transport systems
including basic volume (preloaded volume)
NumTSys

q =

i = 1

( q i PCU i ) + q preloadedVolume

qmax

Capacity [car units/time interval]

Sat

Volume/capacity ratio

Fij

Number of trips [veh/time interval] for relation from zone i to zone j.

Demand matrix which contains the demand for all OD pairs.

Table 47: Abbreviations used in the User model PrT.

5.2

Example network for the PrT assignment procedures


The way the PrT assignment procedures work is described with the example illustrated in
illustration 57. The example analyzes the relation between traffic zone "village A" and traffic
zone "city X". The following assumptions apply:

PTV AG

Access and egress times are not considered, that is, they are set to 0 minutes.
Turn penalties are not considered.
Capacity and demand refer to one hour.

213

Chapter 5: User model PrT

The traffic demand between A-Village and X-City is 2,000 car trips (car.fma matrix) during
peak hour.
To explain simultaneous assignment of multiple demand matrices 200 additional HGV trips
(hveh.fma matrix) are considered. One HGV corresponds to two car units.
On federal roads (link type 20) there is a speed limit of 80 km/h for HGVs.

The example network contains three routes which connect A-Village and X-City. The routes
run via the following nodes:

Route 1: 10 11 41 40
Route 2: 10 11 20 21 30 31 40
Route 3: 10 12 21 30 31 40

Route 1 mainly uses country roads and is 26 km long. It is the shortest route. Route 2 is 30 km
long. It is the fastest route because the federal road can be traversed at a speed of 100 km/h
if there is free traffic flow.
Route 3 which is also 30 km long is an alternative route which only makes sense if the federal
road is congested.
village A
10

10

12

11

11

41

20

40

21

30

city X

31

Illustration 57: Example network


LinkNo

From Node To Node

Type

Length [m]

Capacity [car units/h]

v0-PrT [km/h]

10

20 Federal road

5,000

1,200

100

11

11

20

20 Federal road

5,000

1,200

100

20

21

20 Federal road

5,000

1,200

100

20

40

90 Rail track

10,000

21

30

20 Federal road

5,000

1,200

100

Table 48: Example network

214

PTV AG

Chapter 5.3: PrT Paths

LinkNo

From Node To Node

Type

Length [m]

Capacity [car units/h]

v0-PrT [km/h]

30

31

20 Federal road

5,000

1,200

100

31

40

20 Federal road

5,000

1,200

100

11

41

30 Country road

16,000

800

80

40

41

30 Country road

5,000

800

80

10

10

12

40 Other roads

10,000

500

60

11

12

21

40 Other roads

5,000

500

60

Table 48: Example network

The example network in table 48 is saved to the folder ...Users\Public\Public documents\PTV


Vision\PTV Visum 13\Example_net.

5.3

Version file: Example.ver


Assignment parameters file: Auto.par

PrT Paths
All assignments in Visum in the PrT as well as in the PuT are route based. This means that
possible paths in the assignment are calculated for each origin-destination relation and loaded
with a demand share. All other results, especially the different network object volumes and the
skim matrices are derived from these loaded paths. Paths are therefore the central result of the
assignment procedure.
The table 49 displays the PrT paths provided by an equilibrium assignment in Example.ver, in
link-based display.
Origin zone
100

100

100

Destination zone Path index


200

200

200

Index

Link

From node

To node

1
1

10

11

11

20

20

21

21

30

30

31

31

40

10

11

11

41

41

40

10

10

12

11

12

21

Table 49: Link-based PrT paths of a PrT assignment

PTV AG

215

Chapter 5: User model PrT

Origin zone

Destination zone Path index

Index
3

Link

From node
5

21

To node
30

30

31

31

40

Table 49: Link-based PrT paths of a PrT assignment

For private transport, you can edit paths manually, because paths are available as network
objects here (see "Paths" on page 52).

5.4

Impedance and VD functions


Subjects

5.4.1

Impedance of a PrT route


Predefined VD functions
Example of the calculation of the link impedance
User-defined VD functions

Impedance of a PrT route


All assignment procedures are based on a short-route algorithm that determines low
impedance routes. The impedance of a PrT route is volume-dependent and consists of the
following impedances:

Impedances of used links (see "Impedances of links" on page 217)


Impedances of used turns, which are also called 'node impedance' (see "Impedances at
node" on page 226)
Impedances of the used connectors (see "Impedances of connectors" on page 217)
Impedances of the used main turns (see "Impedances of main turns" on page 218)

The route choices of travelers depend on objective and subjective factors. The route choice is
particularly determined by the following skims:

The anticipated travel time for the route


Route length
Possible road tolls

In addition to this, a multitude of other factors can influence route choice. One can imagine, for
example, that road users who know their way around will choose other routes than people who
do not know the area and who mainly orient themselves according to the sign-posted traffic
network. Impedance is therefore defined for each transport system and can be customized by
the user. By default, it depends on the following variables:

216

Transport system-specific travel time, in loaded network tCur [s]

Link length [m]


Transport system-specific road tolls [money units]
User-defined AddValues
Link type factor [-]

PTV AG

Chapter 5.4: Impedance and VD functions

You can also define the impedance in detail. You are then provided with all direct and indirect
numerical attributes of the network objects links, turns, connectors and main turns, for the
definition of the impedance of a route (see User Manual, Chpt. 5.2.2, page 992).
When composing the impedance summands, it can be differentiated between two basic
components:

Summands, which apply depending on the traffic volumes (for example value calculated
tCur with a VD function)

Summands, which are not dependent on the network object volume (for example, toll or link
length)

The time tCur of a network object is calculated with capacity restraint functions (VD functions).
Based on the assumption that the travel time (impedance) of network objects increases with
increasing traffic volume, all assignment procedures are in turn based on the assumption that
travel times of network objects are a monotone incremental function of traffic volume. Thus, in
case of increased traffic in the network the effect of deterrence to alternative routes can be
modeled (see "Predefined VD functions" on page 218).
Because the variables have different units (seconds, meters, money units), impedance cannot
be written in a universally applicable unit. For a combination of the variables, travel time, and
road toll, it may be convenient to express impedance in terms of money units. In this case,
travel times are converted into money units using a "value of time" factor.

Impedances of links
For every PrT-transport system of a link, a TSys-specific travel time (t0_TSys) for free flow is
defined which is calculated from:

link length
permitted speed (v0_PrT) of the link used

maximum speed of the transport system (v0_PrTSys)

A capacity-dependent impedance function continuously adapts this basic travel time


depending on the current traffic volume (see "Predefined VD functions" on page 218).

Impedances of turns (Impedances at node)


Visum calculates turn impedances for every turn permitted at a node. A turn impedance
includes an impedance time penalty t0 which increases in dependence on volume and
capacity. Because the turns are positioned at the node, the impedances at turns are often
described as impedances at node (see "Impedances at node" on page 226).

Impedances of connectors
Connector impedances are regarded as follows:

PTV AG

Absolute connectors are regarded as being volume-dependent. This means, that the TSysspecific connector time (t0_TSys) does not represent actual impedance which is volumeindependent.

217

Chapter 5: User model PrT

For connectors defined by percentage, they are regarded as volume-dependent, if the


option Connector weights apply to total trips (MPA off) is active. This means, that with
increasing volume the actual connector time tCur_TSys will exceed the connector time
t0_TSys of each connector (see "Predefined VD functions" on page 218). With a high value
for parameter b in the VD function and usage of the equilibrium assignment, a relatively
exact distribution of traffic onto the connectors can be achieved.

Note: The impedance of turns and connectors in contrast to links only depends on the
variable tCur and possibly on the AddValue. Because the impedance of a connector is not
capacity-dependent, the following applies to the access and egress impedance: tCur = t0. The
proportional distribution of traffic demand onto different connectors is, however, reached
through a virtual capacity, so that tCur > t0 can also apply to connectors. For each assignment,
the particular virtual capacity (100%) is then recalculated from the summed up volume total
and the demand to be assigned in the current assignment, e.g. Vol(car-business) + Vol(carprivate) + Demand(HGV) = 100% Connector capacity.

Impedances of main turns


Just like turn impedances, in Visum main turn impedances are calculated for each main turn
permitted at a main node based on the volume and selectively a VD function, TModel or ICA.

Preloaded volume
When impedances are determined, preloaded volumes can be considered. Preloaded volumes
can be either user-defined additional values or volume values which result from the
assignment of a different matrix.

5.4.2

Predefined VD functions
Travel times for PrT are determined by the saturation of links and turns which result from the
traffic volume and the capacity of these network objects. Due to this, PrT travel times vary in
contrast to PuT journey times, and can only be anticipated to a certain degree before a trip. The
PrT travel time of a route between two zones consists of the following components:

Access and egress times


Travel time on links
Turn time at intersections

For free traffic flow, the travel time t0 of a link can be determined from the link length and the
free-flow speed v0. For turns at an intersection, the turn time t0 is specified directly. In loaded
networks, the link travel time and the turn time is determined by a so-called volume-delay
function (or VD function). This capacity restraint function describes the correlation between the
current traffic volume q and the capacity qMax. The result of the VD function is the travel time in
the loaded network tcur. Visum provides several function types for the volume-delay functions:
1. the BPR function from the Traffic Assignment Manual of the United States Bureau of Public
Roads (illustration 58)
2. a modified BPR function with a different parameter b for the saturated and unsaturated
state (table 52)
3. a modified BPR function, for which an additional supplement d per vehicle can be specified
in the saturated state (table 53)

218

PTV AG

Chapter 5.4: Impedance and VD functions

4. the INRETS function of the French Institut National de Recherche sur les Transports et leur
Scurit (illustration 59)
5. a constant function where the capacity does not influence travel time (tCur = t0)
6. and several functions for turning processes (i.e. t0 is added, not multiplied) as well as
function type linear bottleneck which are used by turn type
7. another modified BPR function (LOHSE) with a linear rise in the oversaturated section, in
accordance with the queuing theories, in order to achieve more realistic times in the
oversaturated section and a better performance in assignments since small changes to the
volume do not result in disproportionate travel time changes. The function is monotonic,
continuous, and differentiable even where sat = satcrit
Note: In addition to the volume-delay functions provided in Visum, you can also specify
user-defined VD functions (see "User-defined VD functions" on page 225).
The table 50 shows the variables used in the descriptions of the VD functions.
sat

q
q max c

Volume/capacity ratio sat = ------------------

satcrit

Degree of saturation at which the linear section of the volume-delay function starts

tcur

Current travel time on a network object in loaded network [s] (tCur)

t0

Travel time on a network object with free flow time [s]

Current volume = sum of volumes of all PrT transport systems including preloaded volume
[car units/time interval]
NumTSys

q =
qmax

i = 1

( q i PCU i ) + q preloadedVolume

Capacity [car units/time interval]

Table 50: Variables used in VD functions

The parameters mentioned in table 51 apply to all VD functions. Function-specific parameters


are listed with the respective VD function.

a, b, c

User-defined parameters
a [0.00;), b {0.00...10.00}, c [0.00;)

Table 51: Parameters for all VD functions

PTV AG

219

Chapter 5: User model PrT

Volume-delay graph for a=1 and c=1, tCur = t0 f(q/qMax)


10

f(q/qMax)

6
b=2
b=3

b=4
b=5

0
0

0,2

0,4

0,6

0,8

1,2

1,4

1,6

q / qMax

Illustration 58: VD function type BPR according to the Traffic Assignment Manual

satcrit

satcrit = 1

a, b, b, c

Parameters a [0.00;), b, b {0.00...10.00}, c [0.00;)

Table 52: VD function type BPR2: modified BPR

, where

satcrit

satcrit = 1

a, b, c, d

a [0.00;), b {0.00 ...10.00}, c [0.00;), d {0.00...100.00}

Table 53: VD function type BPR3: modified BPR

with

a, c

a [1.1;100), c [0.00;100)

Table 54: VD function type CONICAL (Spiess)

220

PTV AG

Chapter 5.4: Impedance and VD functions

with

a, c

, where

a [1.1;100), c [0.00;100)

Table 55: VD function type CONICAL_MARGINAL

A marginal-cost version of the CONICAL function, proposed by Spiess to calculate a system


optimum instead of user optimum in equilibrium assignment.

, where

satcrit

satcrit [0.00;10]

a, b, c, d

a [0,0001;100], b [0,0001;10000], c [0.00;100], d [0,0001;10000]

Table 56: VD function type EXPONENTIAL

The function models queuing at entry legs whose inflow is restricted by ramp metering signals.

, where

satcrit

satcrit = 1

current volume = sum of volumes of all PrT demand segments [car units/time unit] including
basic volume (preloaded volume)
AnzNSeg

q =

i = 1

( q i PkwE i ) + q Vorbelastung

user-defined parameter a {0.00..1.10}

user-defined capacity parameter c [0;)

Table 57: VD function type INRETS

PTV AG

221

Chapter 5: User model PrT

Volume-delay graph for c=1, tCur = t0 f(sat)


10

f(sat)

a = 0,0
a = 0,2

a = 0,4
a = 0,6
a = 0,8

0
0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

1,1

1,2

1,3

1,4

1,5

1,6

sat

Illustration 59: VD function type INRETS

The impedance functions listed in table 58 are particularly suited to the modeling of turn
impedances. A capacity-dependent wait time is thus added to each basic wait time t0.
LOGISTIC

QUADRATIC
SIGMOIDAL_MMF_NODES (formerly SIGMOIDAL_MMF)

SIGMOIDAL_MMF_LINKS (formerly SIGMOIDAL_MMF2)


Unlike SIGMOIDAL_MMF_NODES, the wait time term is not added
to t0 but multiplied by it.

a, b, c, d

Table

222

a, b, c, d [0.00100.00}, f {0.00...10.00}.
The value of parameter f of VD function types SIGMOIDAL_MMF_NODES and
SIGMOIDAL_MMF_LINKS ranges from 0..100.
58:
VD
function
types
SIGMOIDAL_MMF_LINKS

LOGISTIC,

QUADRATIC,

SIGMOIDAL_MMF_NODES,

PTV AG

Chapter 5.4: Impedance and VD functions

AKCELIK

The function describes delays at nodes with


a = duration in hours
b = family parameter
d = capacity of lane per hour
Table 59: VD function type AKCELIK
AKCELIK2

a = duration in hours
b = family parameter
d = 1 / Number of lanes (of the link)
qmax = capacity of the network object (of the link)
Unlike AKCELIK, the denominator of this function references directly to the capacity of the network
object. Besides, AKCELIK2 is no wait time function at a node but models the speed reduction on a link.
Value d is intentionally a free parameter, although alternatively the link attribute 'Number of lanes' could
be evaluated directly. By removing this attribute which should always carry the physically existing number
of lanes (for example for the Vissim export), a suitable value of d for example, can model the frictional
loss by pulling in and out events for parking. d = 0.6 would therefore correspond to a slightly lower
capacity than two lanes.
Table 60: VD function type AKCELIK2

satcrit

satcrit [0.00;10]

[(a + 1) t0] represents tCur with sat = 1

a [0.00;1000]
b

Determines the value of the increasing rise up to sat = satcrit

b [0.00;10]
c

Scaling parameter for the determination of the dimensions of q and qmax

c [0.00;100]
Table 61: VD function type LOHSE

PTV AG

223

Chapter 5: User model PrT

LOHSE
45,0
40,0
35,0
30,0
tcur

b=2
25,0

b=3
b=4
b=5

20,0
15,0
10,0
5,0

2,50

2,40

2,30

2,20

2,10

2,00

1,90

1,80

1,70

1,60

1,50

1,40

1,30

1,20

1,10

1,00

0,90

0,80

0,70

0,60

0,50

0,40

0,30

0,20

0,10

0,00

0,0

sat

Illustration 60: VD function type LOHSE


Linear bottleneck

This function type stems from Metropolis and should not be used in static assignments, as it rises
strongly when reaching the saturation while the previously augmenting VolCapRatio is unaccounted for.
Table 62: VD function type Linear Bottleneck

Some projects may require non-standard VD functions, e.g. because they include further link
attributes or because the conversion of volumes to passenger car units (PCUs) is projectspecific. In this case, you can add your own functions to the pre-defined volume-delay
functions (see "User-defined VD functions" on page 225).

5.4.3

Example of the calculation of the link impedance


The table 63 to table 66 show an example in which link impedance consists of the current
travel time and road toll. For HGV transport systems which have a higher "value of time" the
influence of road tolls on link impedance is less than for car transport systems.
Link length

10,000 m

Permitted maximum speed v0 car

130 km/h

Permitted maximum speed v0 HGV

100 km/h

Road toll for cars

Road toll for HGV

Capacity

3,000 car units/h

Table 63: Input data of the calculation of the link impedance

224

PTV AG

Chapter 5.4: Impedance and VD functions

Car volume

1,000 cars/h = 1,00 car units/h

HGV volume

100 HGV/h = 200 car units/h

Value of time VOTcar

18 /h = 0.005 /s

Value of time VOTHGV

36 /h = 0.010 /s

VD function according to BPR

with a = 1, b = 2, c = 1

Table 63: Input data of the calculation of the link impedance

Car travel time in unloaded network

t0 car = 10,000 3.6 / 130 = 277s

Car travel time in loaded network

tCur car = 277 (1+(1,200/3,000)) = 321s

Car speed in loaded network

vCur car = 10,000 3.6 / 321 = 112 km/h

Table 64: Car travel times and speeds


HGV travel time in unloaded network

t0 HGV = 10,000 3.6 / 100 = 360s

HGV travel time in loaded network

tCur HGV = MAX (321s; 360s) = 360s

HGV speed in loaded network

vCur HGV = 100 km/h

HGV speed only declines if the volume is more than 1644 car units/h, if
tCur = 277 (1+(1644/3000)) = 360s
Table 65: HGV travel times and speeds
Car impedance in loaded network

RCar = 1 + 0.005 321 = 2.61

HGV impedance in loaded network

RHGV = 5 + 0.010 360 = 8.60

Table 66: Calculation of link impedance for HGV and car

5.4.4

User-defined VD functions
You can set up user-defined VD functions for the following use cases:

To include further attributes for links, turns and connectors in the calculation
To calculate PCUs in a non-standard way
To define separate volume-delay functions for different transport systems

Volume-delay functions are very often evaluated within the assignment methods, so
computational efficiency is a key consideration. Therefore Visum adopts a compiled rather
than an interpreted approach to user-defined volume-delay functions. Users program their
functional forms as a dynamic-link library (DLL) following a given template. All such *.dll files
need to be copied into the following project directory, which is created during the installation
and which is scanned by Visum at start-up: %APPDATA%\PTV Vision\PTV Visum
13\UserVDF-DLLs (see User Manual, Chpt. 5.2.1.6, page 984).
Note: A *.bmp file with identical file name which is stored in the same folder will be displayed
for VDF selection.

PTV AG

225

Chapter 5: User model PrT

5.5

Impedances at node
Intersections are modeled as nodes or as main nodes in Visum. Intersections of roads and/or
railway tracks are bottlenecks in an urban transport network. At the intersections, conflict
points have to be passed in succession by the non-compatible traffic flows. The order in which
the flows traverse the conflicting areas depends on the type of control:
To choose the route within an assignment procedure, the impedance on alternative routes is
decisive, which results in the sum of impedances of all traversed network objects. The
bottleneck effect of a node is thus displayed for all variants of the traffic control by the
impedance of the turn used. The impedance of turns usually corresponds exactly to the travel
time tCur, thus the time required to traverse the node in the turning direction of the route.
For calculating tCur per turn Visum offers three different models that represent the different
compromises between data entry and computing time on the one hand and accuracy and reallife situations on the other.

Turns VDF (see "Impedance of turns from Turns VD function" on page 228)
Nodes VDF (see "Impedance of turns from Nodes VD function" on page 228)
Intersection Capacity Analysis ICA (see "Intersection Capacity Analysis according to the
Highway Capacity Manual (ICA)" on page 229)
To use ICA during assignment, select the method Node impedance calculation (ICA).
Alternatively you can based on an assignment result select method From previous
assignment with ICA.

Comparing advantages and disadvantages in table 67 is to help you choose the appropriate
calculation model for your project.
Model

Advantage

Disadvantage

Turns VDF (see


Little input complexity (per turn
"Impedance of turns
merely capacity and t0)
from Turns VD
Calculation fast
function" on page 228) Assignment fast convergence

Time required for the turning


movement only takes the turning
volume into account, not the amount
of possible conflicting volumes
(separable cost functions)

Nodes VDF (see


Input complexity only slightly larger
"Impedance of turns
than for turn VD functions
from Nodes VD
(additionally capacity and t0 for the
function" on page 228)
node itself as well as designating
subordinated links)
Calculation fast
For subordinate turns at two-way
stop nodes, the time required due to
its own volume increases by an
additional penalty, which depends
on the total volume/capacity ratio of
the node and therefore on the
volumes of conflict flows.

Assignment convergence slower due


to the inseparable penalty
Compared to ICA, taking conflicting
volumes into account is extremely
simpler due to the fixed penalty

Table 67: Advantages and disadvantages of the node impedance model

226

PTV AG

Chapter 5.5: Impedances at node

Model

Advantage

Disadvantage

Node impedance
Impedance calculation precisely
Input complexity considerably higher:
calculation (ICA) (see
considers lane allocation and signal
Instead of capacity and t0, model the
"Intersection Capacity
control. Special turn pockets for
lane allocation at the node and Analysis according to
example, are capacity-increasing
where available - the signal control in
the Highway Capacity
and dependent on the entered signal
detail
Manual (ICA)" on
timing, protected and permitted turns Calculation more time consuming
page 229)
are calculated correctly
Assignment convergence slow due to
the inseparable impedance model,
sometimes without additional
measures not at all
From previous
assignment with ICA
(see "Assignment with
ICA" on page 354)

In the Assignment with ICA,


Increased efforts required for the
convergence is reached by regular
comprehensive modeling of
adjustment of the Turns VDFs to the
geometry and control at the nodes to
wait times and capacities calculated
be regarded.
by ICA.
Comparably computation timeconsuming.
The HCM 2000 method used for ICA
regards the lane allocation and
conflicting turn flows in detail.

Table 67: Advantages and disadvantages of the node impedance model

Due to the reasons mentioned we recommend the following for the selection.

For comprehensive models, modeling with VD functions for turns or nodes is appropriate.
ICA cannot be recommended here, because the input complexity for the detailed supply of
nodes with geometry and control data is usually too high. Furthermore, the result after each
acceptable computing time due to the slow convergence of the assignment still contains
approximation errors, which are around the same size as the accuracy gained through ICA.
ICA however, is the method of choice if you want to subsequently calculate and analyze the
performance of one or more nodes of an existing assignment result. This is how you can
determine which aspects of the node contribute to a high impedance. It is therefore
sufficient to only model those nodes completely which have to be analyzed.
With a classical assignment method (Equilibrium or Equilibrium_Lohse, for example), ICA
is only conditionally recommended due to the known convergence difficulties, and it should
only be applied to small-scale analyses with some 100 nodes. To avoid these problems, the
Assignment with ICA method is recommended.
With an equilibrium assignment, best results can be achieved with either the
Equilibrium_Lohse method (see "Equilibrium_Lohse" on page 346) or the From
previous assignment with ICA method (see "Assignment with ICA" on page 354), since
these are more robust towards impedance variations.

In most cases you will globally decide on a calculation model. You can however also combine
different calculation methods within a network, (for example, Turns VD functions as standard
model and ICA simply for very important nodes with complex lane allocation or large conflicting
flows).
All calculation models are based on turn volumes in car units per hour, which are determined
through the user's settings, either from the assigned volume or from counted data via a factor.

PTV AG

227

Chapter 5: User model PrT

5.5.1

Impedance of turns from Turns VD function


In the simplest calculation model tCur, the time requirement of a turning vehicle is calculated
from the turning time t0 in the unloaded network and the saturation of turns using a VD function.
You can use one of the pre-defined functional forms (see "Predefined VD functions" on
page 218) as VD functions or select a user-defined functional form (see "User-defined VD
functions" on page 225). Typical Turn VD functions make up the sum (not the product) of t0 and
a saturation-dependent term. Examples are the VD functions Akcelik, Exponential, Constant,
Logistic, Quadratic and TMODEL_Nodes.
The attributes mentioned in table 68 are considered for the calculation.
Network object

Attribute

Turn

Capacity PrT The capacity of the turn in PCUs/hour

Description / Effect

Turn

t0 PrT

The time required for a turning movement in unloaded state

Turn

Type

Usually specifies the direction of the turn

Table 68: Attributes for the impedance calculation from Turns VD function

5.5.2

Impedance of turns from Nodes VD function


In this model, turn delays are calculated in two steps. First, a node delay is calculated by
applying a VD function to the vol/cap ratio of the node. Each turn penalty is the sum of node
delay and the turn-specific time (calculated with VD function set for turns). Node delay only has
an affect on turns from a non-prioritized approach. This approach links have to be marked with
the attribute TModelSpecial (see User Manual, Chpt. 2.40, page 578).
The attributes mentioned in table 69 are considered for the calculation.
Network object Attribute

Description / Effect

Turn

Capacity PrT The capacity of the turn in PCUs/hour

Turn

t0 PrT

The time required for a turning movement in unloaded state

Turn

Type

Usually specifies the turning direction

Node

Capacity PrT The total capacity of the node in PCUs/hour

Node

t0 PrT

The additional time required for a non-prioritized turning movement (all


the same) in unloaded state

Table 69: Attributes for the impedance calculation from Node VD function

Turn time penalties are calculated according to the following formulas:


vol(n) = vol(t)
delay(n) = VDF (cap(n), vol(n))
delay(t) = VDF (cap(t), vol(t))

IF n has no link with TModelSpecial = 1, THEN


tCur(t) = delay(t) + delay(n) for all turns t via node n

228

PTV AG

Chapter 5.5: Impedances at node

IF n has at least one link with TModelSpecial = 1, THEN


tCur(a) = delay(t) for all turns t with a 'from link' to which TModelSpecial = 0 applies
tCur(a) = delay(t) + delay(n) for all turns t with a 'from link' to which TModelSpecial = 1 applies

5.5.3

Intersection Capacity Analysis according to the Highway Capacity


Manual (ICA)
VD functions are usually used to model volume-dependent travel times on links (see
"Impedance and VD functions" on page 216). They can also be used to model volumedependent wait times for turns or complete nodes (see "Impedance of turns from Turns VD
function" on page 228 and "Impedance of turns from Nodes VD function" on page 228).
By contrast the Highway Capacity Manual (HCM) published by the US Transportation
Research Board contains internationally recognized guidelines on calculating the level of
service and other performance indicators for intersections, based on the detailed junction
geometry and various control strategies. Visum computes performance indicators such as
capacity, delays or LOS either according to the guidelines defined in the operation model HCM
2000 or according to HCM 2010 guidelines.
Note: In the following the implementation of the HCM 2000 in Visum is described. For most
of the control types (except for signalized nodes), the HCM 2010 differs from the HCM 2000
in only a few aspects. The deviating portions are highlighted in the text. Since the HCM is
provided in English only, certain English expressions and descriptions have not been
translated for a better traceability in the original document.
For intersection points of the same level, the calculation differentiates between the following
control types (attribute Effective control type at node):

Uncontrolled nodes (see "Uncontrolled nodes" on page 230)


Signalized intersections (see "Signalized nodes" on page 230)
Static priority rules using the traffic signs StVO 306 or 301 (German road traffic regulations)
for the main road and StVO 205 or 206 for the subordinate road (see "Two-way stop nodes"
on page 250)
All-Way stops (only for North America) (see "All-way stop" on page 260)
Roundabouts
Visum offers two different models for the analysis of roundabouts:

The method developed by R. M. Kimber, (Kimber 1980), (Kimber, Hollis 1979), (Kimber,
Daly 1986), which is also described in the British guideline TD 16/93 "The Geometric
Design of Roundabouts", is based on the empirical study of numerous roundabouts and
the statistical adjustment of a model which estimates capacities in dependency of the
geometry (see "Roundabouts according to the TRL/Kimber 2010 method" on
page 272).
The method described in the Highway Capacity Manual 2010, chapter 21 (see
"Roundabouts according to the HCM 2010 method" on page 267).

The method according to TRL/Kimber has the advantage of taking comprehensive


empirical results on the influence of geometry on the permeability of a roundabout into
consideration and has been successfully implemented for nearly three decades.

PTV AG

229

Chapter 5: User model PrT

The method according to HCM is recommended, if in theory you prefer consistency for all
control types (roundabouts also according to HCM like signalized and two-way stop nodes)
within a project. Furthermore, the method is not dependent on observations which were
only obtained through driving behavior studies in Great Britain.
For the calculation, the effective control type is decisive instead of the control type. These
values differ in the following: Signalized nodes are regarded as yield-controlled nodes, if no SC
has been allocated to them or if the SC has been turned off (Signal control attribute Turned
off).
Notes: Throughout the model description, special provision for right or left turns relates to
right-hand traffic. For Visum models with left-hand traffic the roles of right and left turns are
reversed (see User Manual, Chpt. 1.5, page 65).
U-turns are never considered in HCM 2000. In Visum it is possible to treat U-turns as far left
turns through the corresponding setting in the procedure parameters for intersection
impedance analysis (in left-hand traffic accordingly as far right turns). This calculation is then
no longer HCM conform. HCM 2010 regards U-turns at two-way stop nodes. Here, the
processing is performed according to HCM 2010 in Visum. Other control types are processed
according to HCM 2000.

5.5.3.1

Uncontrolled nodes

For uncontrolled nodes the impedance of a turn is calculated using a VD function from the node
volume (= Sum of turn volumes) and the node capacity, therefore exactly like calculating the
model Nodes VD function (see "Impedance of turns from Nodes VD function" on page 228),
however without a term for each turn.
The Visum attributes listed in table 70 are considered for the calculation.
Network object Attribute

Description / Effect

Node

Capacity PrT The total capacity of the node in PCUs/hour

Node

t0 PrT

The time required in a turning movement (all equal) in unloaded state

Table 70: Attributes for the calculation regarding uncontrolled nodes

5.5.3.2

Signalized nodes

Notes: In the HCM 2000, chapter 16 describes signalized nodes. In HCM 2010, find the
descriptions in the chapters 18 and 31.
Instead of the method described here for signalized nodes, the method for yield-controlled
nodes is applied to nodes and main nodes of the signalized control type, to which no SC has
been allocated or whose SC has been turned off.
The basic flow chart for performing capacity analyses for signalized intersections is displayed
in illustration 61. You input the intersection geometry, volumes (counts or adjusted demand
model volumes), and signal timing. The intersection geometry is deconstructed into lane (or
signal) groups, which are the basic unit of analysis in the HCM method.

230

PTV AG

Chapter 5.5: Impedances at node

A lane (or signal) group is a group of one or more lanes on an intersection approach having the
same green stage. For example, if an approach has just one pocketed exclusive left turn and
one shared through and right turn, then there are usually two lane groups the left and the
shared through/right.
Note: According to HCM 2010, the lane allocation follows different rules. Here, shared lanes
always form a separate lane group. For more details, please refer to HCM 2010, page 18-33.
The volumes are then adjusted via peak hour factors, etc. For each lane group, the saturation
flow rate (SFR), or capacity, is calculated based on the number of lanes and various
adjustment factors such as lane widths, signal timing, and pedestrian volumes. Having
calculated the demand and the capacity for each lane group, various performance measures
can be calculated. These include, for example, the v/c ratio, the average amount of control
delay by vehicle, the Level of Service, and the queues.

I n p u ts
Ge om etry
V olum es
S ig nal tim in g

L a n e G ro u p s &
D em an d A d j
L an e Gro uping s
P ea k h our fa ct or

S atu ratio n F lo w R a te
(C ap a city)
Ba sic s
A djus tm en t F a ct ors

C ap ac ity A n alysi s
V /C R a tio
A v erage D elay
L ev el o f S ervic e
Qu eue s

Illustration 61: Capacity analysis process for signalized nodes

Note: For HCM 2010, the corresponding flow diagram can be found in HCM 2010, page 1832.
If you use the HCM 2000 or HCM 2010 operations model for signalized nodes, the Visum
attributes in table 71 will have an effect. Make sure that they are set to realistic values prior to
running the analysis.
Alternatively to the calculation method according to HCM, you can apply one of the following
methods:

PTV AG

ICU1
ICU2

231

Chapter 5: User model PrT

Circular 212 Planning


Circular 212 Operations

From the HCM, these procedure differ in just three issues:

Definition of the ideal saturation flow rate


Calculation of the final saturation v/s (volume/saturation flow rate) for the node
Determination of the Level of Service (LOS)

The steps 6, 9 and 13 below describe the calculation variants in detail.


Note: Visum allows for control access to RBC and Vissig controllers. Vissig controllers
provide fixed-time control strategies. RBC controllers provide pre-timed or actuated control
strategies (also fully or semi-actuated). HCM 2010 provides a computation method for fixedtime strategies and for traffic-actuated strategies as well. Visum uses fixed-time strategies for
Vissig controllers. The strategy used for RBC controllers depends on the type of traffic
actuation. For a description of this method, please refer to HCM 2010, chapters 18 and 31.
Prior to the computation, Visum imports the signal control data for the control strategy from
the corresponding control file.
Network object

Attribute

Description / Effect

Link

ICAArrivalType

Level of platooning in traffic arriving at the ToNode,


subsequently used in the steps 10 + 14a

Link

ICAUpstreamAdj

Adjustment factor for upstream filtering / metering, used in


the steps 10b + 14b

Link

ShareHGV

Proportion of heavy goods vehicles, used in step 6b. One


value applies to all turns originating from the link

Link

Space per PCU

Used in step 6 for the calculation of the number of vehicles


that fit on a pocket lane

Link

Slope

Used in step 6

Node

ICAPHFVolAdj

Factor for adjustment of initial volumes to peak volumes.


Volumes are divided by both node and turn adjustment
factors.

Node

ICALossTime

Used in step 9. Only required for SG-based signal control.


For other types of signal control the value is inferred
automatically.

Node

ICAUsePresetLossTime Decides whether the node attribute ICALossTime is to be


used or an automatically calculated value for the loss time
computation in step 9.

Node

ICAIsCBD

Is the node located in the Central Business District?; used in


step 6e

Node

ICASneakers

Number of vehicles which can line up in the node area


during a cycle. The value in [veh] applies to all movements
at the node The cycle time is used for the minimum capacity
calculation for each movement.

Node

SC number

Points to the signal control

Table 71: Input attributes for signalized nodes

232

PTV AG

Chapter 5.5: Impedances at node

Network object

Attribute

Description / Effect

Geometry

All

Geometry data of lanes, lane turns and crosswalks

Turn

ICAPHFVolAdj

Initial volume adjustment to peak period; volumes are


divided by both node and turn adjustment factors

Turn

ICA Preset saturation


flow rate

Overwrites optionally the global saturation flow rate in the


procedure parameters. Can be overwritten by the specific
lane value of this attribute, if applicable.

Signal Control

All

Definition of signal groups, stages (where applicable), and


signal timing

SC

Used intergreen method Is used in step 9 for loss time calculations

SC

Turned off

If an SC is marked as 'turned off', the node will be calculated


according to the yield control control type.

Signal group

ICA loss time


adjustment

Is added to the actual green time. The actual green time and
ICA loss time adjustment sum up to the green time on which
all computations are based.

Leg

ICA bus blockage

Adjustment factor for the saturation flow rate for


consideration of bus stops.

Leg

ICA parking

Adjustment factor for the saturation flow rate for


consideration of parking events.

Leg

Bicycle volume

Number of bicyclists per hour for the determination of the


adjustment factor for the saturation flow rate.

Lane

Number of vehicles

User-defined number of vehicles 0.0 the pocket


accommodates. This attribute is only regarded if the attribute
Use number of vehicles is true and if the global procedure
parameter 'Regard pocket length for saturation flow rate
calculation' is active.

Lane

Use number of vehicles

Decision, whether Number of vehicles of the lane shall be


used. If this attribute is not true, the number of vehicles is
determined from the pocket length and the attribute Space
per PCU.

Lane

Length

Lane length if pockets are concerned. This attribute is only


regarded if the attribute Use number of vehicles is not true
and if the global procedure parameter 'Regard pocket length
for saturation flow rate calculation' is active. The number of
vehicles is calculated from the length of the pocket and the
attribute Space per PCU.

Lane

Width

Width of the lane. On this basis, the saturation flow rate is


calculated for the lane group to which the lane belongs. The
calculated lane group width is the mean value derived from
the width values of all lanes of this group.

Table 71: Input attributes for signalized nodes

PTV AG

233

Chapter 5: User model PrT

Network object

Attribute

Description / Effect

Lane

ICA Preset saturation


flow rate

Saturation flow rate for the lane after consideration of all


adjustment factors. Use this attribute to set the saturation
flow rate directly, if the HCM-based adjustment factors do
not reflect the actual circumstances of the lane. This value
overwrites the procedure parameter value and also turnrelated values, if applicable.

Lane

ICA Use preset


saturation flow rate

Decision, whether the internally calculated saturation flow


rate shall be replaced by the ICA Preset saturation flow
rate value.

Lane

ICA user-defined
utilization share

Utilization share of the lane within a multi-lane group. The


sum of the input shares is automatically scaled to 100%,
thus you can enter relative weights per lane. This value is
used in step 6.

Lane

ICA use user-defined


utilization share

Decision, whether the internally calculated utilization share


shall be replaced by the ICA user-defined utilization share
value.

Crosswalk

Pedestrian volume

Number of pedestrians per hour for the determination of the


adjustment factor for the saturation flow rate.

Table 71: Input attributes for signalized nodes

Notes: The link attribute Turn on red is not regarded for calculation.
Output is possible through the attributes listed in table 72.
Network object Attribute

Description / Effect

Node

Turn tCur maximum


Turn tCur mean
Turn tCur total

Sum, average, max of turn tCur. Now obsolete, since


available as indirect attributes, but retained for
backward compatibility.

Node

Design volume capacity ratio


PrT

The volume/capacity ratio based on the design


volume

Node

Design volume PrT [veh]

The volume in [veh/h] passed into the HCM


calculation, as defined in the procedure parameters

Node

Design volume PrT [PCU]

The volume in [PCU/h] passed into the HCM


calculation, as defined in the procedure parameters

Node

Level of service

Node

Level of service mean delay

Turn

Design volume PrT [veh] ...

The volume in [veh/h] passed into the HCM


calculation, as defined in the procedure parameters

Turn

Design volume PrT [PCU]...

The volume in [PCU/h] passed into the HCM


calculation, as defined in the procedure parameters

Turn

ICA final volume

After all adjustments

Turn

ICA final capacity

Effective capacity, taking into account all opposing


flows etc.

Table 72: Output attributes for signalized nodes

234

PTV AG

Chapter 5.5: Impedances at node

Network object Attribute

Description / Effect

Turn

ICA final saturation flow rate

After all adjustments

Turn

ICA average back of queue

Average queue length

Turn

ICA back of queue for defined


percentile

Percentile of queue length. Specify in the procedure


parameters which percentile is calculated.

Turn

Level of service

Level of service of the turn

Turn

tCur-PrTSys

TSys-specific travel time tCur in loaded network

Table 72: Output attributes for signalized nodes

Step 1: Lane volume calculation from the movement volumes


This step distributes the movement volumes to lanes according to the user-defined geometry.
The basic distribution rule is to distribute the volumes uniformly to the lanes while taking the
input movement volumes into account. The implemented method is the same as in the All-Way
stop method (see "All-way stop" on page 260). You can overwrite a lane's utilization share
within its lane group, if applicable (lane attribute ICA user-defined utilization share).
Here, HCM 2010 and HCM 2000 differ significantly. According to HCM 2010, the calculation is
much more complex. In HCM 2010, lane volume calculation is an iterative process taking the
saturation flow rates into account. For a description, please refer to HCM 2010, pages 31-30 to
31-37.

Step 2: Volume adjustments by means of peak hour factors


The input lane volumes are adjusted to represent the peak hour volumes through the peak
hour factor (phf). The phf is defined as:
vi = vg / PHF

where
vi

adjusted volume for lane group i

vg

unadjusted (input) volume for lane group g

PHF

peak hour factor (0 to 1.0)

Step 3: Calculation of de facto lane groups left/though/right


De facto lane groups are shared lanes with 100% of their volume making one movement. For
example, if a lane group is a shared left and through lane, and 100% of the lane volume is
making a left movement, then the lane group is converted to a de facto exclusive left lane
group.
In the HCM 2010, the set of lane groups is not affected by the volumes of turning movements.
As described above, shared lanes always form a lane group of its own, even if only a single
turning direction is used actually.

Step 4: Calculation of the types of left turns


The type of left turn needs to be determined in order to calculate the left turn adjustment factor.
The left turn type is set as follows:
1. Fully controlled if all turns of an approach are conflict free during their green times.
2. Fully secured if the left turns are conflict free during green time.

PTV AG

235

Chapter 5: User model PrT

3. Fully secured + permitted if during green time left turns are first fully secured and then
permitted.
4. Permitted + fully secured if during green time left turns are first permitted and then fully
secured.
5. Without left turn stage, all other cases.

Step 5: Proportions of left turning and right turning vehicles calculation by lane
group
The proportion of right and left turn volume by lane group needs to be calculated.
PLT = vLT / vi
PRT = vRT / vi

where
PLT

proportion left turn volume by lane group

PRT

proportion right turn volume by lane group

vi

adjusted volume by lane group

vLT

volume of left turning vehicles by lane group

vRT

volume of right turning vehicles by lane group

In HCM 2010, the iterative method mentioned in step 1 is used for the calculation of the turning
movement proportions on shared lanes. For the description in detail, please refer to HCM
2010, page 31-30 et seqq.

Step 6: Saturation flow rate calculation by lane group


The saturation flow rate is the amount of traffic that can make the movement under the
prevailing geometric and signal timing conditions. The saturation flow rate starts with an
optimum capacity, which is usually is 1,900 vehicles per hour, per lane (vphpl), according to
HCM 2000 and HCM 2010.
For calculation variants ICU1 and ICU2, however, the ideal saturation flow rate is 1,600
vehicles per hour, per lane. For the Circular 212 variant, it is taken from the table below:
Method

2 stages

3 stages

4+ stages

Planning

1,500

1,425

1,375

Operations

1,800

1,720

1,650

This number decreases due to various factors. The SFR is defined as:
si = (so)(N) (fw)(fHV)(fg)(fp)(fa)(fbb)(fLu)(fRT)(fLT)(fLpb)(fRpb)

where

236

si

saturation flow rate of lane group i

so

ideal saturation flow rate per lane (generally 1,900 vphpl)

N
fw

Number of lanes in lane group

fHV

HGV adjustment factor

factor for lane width adjustment

PTV AG

Chapter 5.5: Impedances at node

fg

adjustment factor for approach grade

fp

adjustment factor for parking

fa

adjustment factor for the position of the link to city center (CBD true/false)

fbb

adjustment factor for bus stop blocking

fLu

adjustment factor for lane usage

fRT

adjustment factor for right turns

fLT

adjustment factor for left turns

fLpb

adjustment factor for pedestrians and bicyclists on left turns

fRpb

adjustment factor for pedestrians and bicyclists on right turns

First the description of the main calculation is described and then the various SFR adjustment
factors are calculated.
If an ICAIdealSatFlowRate is specified for a turn, it will replace the final result of step 5. All
adjustment calculations are then bypassed.
The calculations according to HCM 2000 or HCM 2010 are similar. The set of factors taking
effect on the saturation flow rate is the same. Merely the calculations of the factors fw (HCM
2010, page 18-36), fLpb and fRpb differ. The latter are calculated by means of the iterative
method, which is described in HCM 2010, pages 31-30 to 31-37.
Deviating from HCM, the optimal saturation flow rate so of pocket lanes can also be calculated
by the number of vehicles which can be accommodated there. The number n of vehicles can
be set by lane. Alternatively, it results from the division of the pocket lane length by the
standard vehicle length which is set by link.
The alternative calculation method using lane length data is only applied, if the lane group
consists of one or more straight through lane(s) and exactly one pocket lane. The pocket lane
must be of a straight through lane or a through-left type or a through-right type lane. If these
conditions are not satisfied, the regular HCM calculation method will be applied.
The optimal saturation flow rate so of a two-lane group, which consists of a through lane and a
pocket, where there is space for n vehicles, then is as follows:
n 3600
s f = s o + min s o, --------------------
gi

Here, so is the ideal saturation flow rate, n is the number of vehicles which can be
accommodated on the pocket, gi is the effective green time and sf is the resulting saturation
flow rate of the lane group.
For shared lanes, the calculation is more complex. Taking a through lane with only straight
turns and a shared left/straight pocket, then the resulting saturation flow rate sf is as follows:
s ST s LT
s f = --------------------------------------------------------------------------v LT
v ST
- s LT
-------------------- s ST + ---------------------v LT v ST
v LT + v ST

PTV AG

237

Chapter 5: User model PrT

Here, vLT and vST are the volumes of the left and the straight turns, sLT is the ideal saturation
flow rate of the left turn - therefore 1,900 vphpl - and sST is the ideal saturation flow rate of the
through lanes which results from the first equation.

Step 7: Calculation of actual green times


The effective green time (or actual green time for a lane group) needs to be calculated next.
The effective green time results as follows:
gi = Gi + li

where
gi

effective green time per lane group

Gi

green time per lane group

li

loss time adjustment per signal group

Step 8: Capacity calculation per lane group


Related to the SFR is the capacity. The saturation flow rate is the capacity if the movement has
100 % of the green time (this means, the signal is always green for the movement). The
capacity, however, accounts for the fact that the movement must share the signal with the
other movements at the intersection, and therefore scales the SFR by the percent of green
time in the cycle. The capacity of a lane group is then defined as follows:
ci = si (gi / C)

where
ci

capacity i

si

saturation flow rate i

C
gi / C

cycle time
green ratio i

Step 9: Calculation of the critical vol/cap ratio for the entire intersection
The critical v/c ratio of nodes is defined below. The HCM method is concerned with the critical
lane group for each signal stage. The critical lane group is the lane group with the largest
volume/capacity ratio unless there are overlapping stages. If there are overlapping stages,
then the maximum of the different combinations of the stages is taken as the max. For the
description of this method, please refer to HCM 2000, page 16-14, or HCM 2010, page 18-41.
Only if the intergreen method Amber and allred is used for the signal control, loss times will be
determined at all. Per signal group, the loss time results from the amber time and allred time
total minus loss time adjustment.
Xc =

i -s- ci + C-----------L

where
Xc

238

critical saturation (v/c ratio) per intersection

PTV AG

Chapter 5.5: Impedances at node

v--
s ci

volume/capacity ratios for all critical lane groups

C
L

cycle time
loss time total of the signal groups of all critical lane groups

Below is an example calculation of critical lane group per signal stage with overlap.
For computation variant ICU1, Xc is defined as follows:
Xc =

i -s- ci + ---Cv

For computation variant ICU2, Xc is defined as follows:

Xc =

i -s- ci
v

1 1 + -----------------C
----
L 1

Step 10: Mean total delay per lane group


In addition to calculating the critical v/c per intersection, the mean delay per vehicle is
calculated by the HCM method. The mean total delay is defined below.
di = dUiPF + dIi + dRi

where
di

mean delay per vehicle for lane group

dUi

uniform delay

dIi

incremental delay (stochastic)

dRi

delay residual demand

PF

permanent adjustment factor for coordination quality (see "Signal coordination (Signal offset
optimization)" on page 281)

In HCM 2010, the equation looks likewise. However, factor PF has been implemented in factor
dUi. For the description of the calculation procedure, please refer to HCM 2010, page 18-45.
1 R g----i f
P C
PA

PF = ------------------------------------------gi
1 ---C

where

PTV AG

fPA

lookup value (HCM attachment 16 12) based on arrival type

RP

lookup value (HCM attachment 16 12) based on arrival type

239

Chapter 5: User model PrT

Step 10a: Calculation of the uniform delay for each lane group
The uniform delay is the delay expected given a uniform distribution for arrivals and no
saturation. It is calculated as follows:

d Ui

2
1 g----i

C
= 0.5 C ------------------------------------------------------g
i
1 ---- ( min ( X i, 1 ) )
C

where
dUi

uniform delay for lane group i

gi

effective (actual) green time

Xi = v/c

volume/capacity ratio

Step 10b: Calculation of the incremental delay for each lane group
The incremental delay is the random delay that occurs since arrivals are not uniform and some
cycles will overflow. It is calculated as follows:
2 8 ki Ii Xi
d Ii = 900 T ( X i 1 ) + ( X i 1 ) + ----------------------------ci T

where
dIi

incremental (random) delay for lane group i

ci

capacity for lane group i

Xi = v/c

volume/capacity ratio

T
ki

duration of analysis period (hr) (default 0.25 for 15 min)

Ii

upstream filtering / metering adjustment factor (set to 1 for isolated intersection)

lookup value (HCM attachment 16 13) based on the controller type

Step 10c: Delay calculation for the residual demand per lane group
The residual demand delay is the result of unmet demand at the start of the analysis period. It
is only calculated if an initial unmet demand at the start of the analysis period is input (Q). It is
set to 0 in the current implementation. It is calculated as follows:
1800 Q bi ( 1 + u i ) t i
d Ri = -------------------------------------------------------ci T
where

240

dRi

residual demand delay for lane group i

Qbi

initial unmet demand at the start of period T in vehicles for lane group (default 0)

ci

Capacity

T
ui

duration of analysis time slot (hr) (default 0.25 for 15 min)


delay parameter for lane group (default 0)

PTV AG

Chapter 5.5: Impedances at node

ti

duration of unmet demand in T for lane group (default 0)

Step 11: Delay calculation for the approach


The total delay per vehicle for each lane group can be aggregated to the approach and to the
entire intersection with the following equations. The approach delay is calculated as the
weighted delay for each lane group.

di Vi
d A = -------------------- Vi
where
dA

mean delay per vehicle for approach A

di

delay for lane group i

Vi

volume for lane group i

Step 12: Delay calculation for the intersection


The intersection delay is calculated as the weighted delay for each approach.

dA VA
d I = ----------------------- VA
where
dI

mean delay per vehicle for intersection I

dA

delay for approach

VA

volume for approach

Step 13: Level of Service calculation


For the computation variant HCM 2000, the level of service is defined as a value which is
based on the mean delay of the node.
LOS

Mean delay/vehicle

0 10 sec.

10 20 sec.

20 35 sec.

35 55 sec.

55 80 sec.

80 + sec.

In HCM 2010, the level of service is automatically classified as F, if v/c (volume/capacity ratio)
exceeds the value 1.
For the variants ICU 1, ICU2, and Circular 212, the level of service is defined through the
saturation v/s (volume/saturation flow rate) of the node:
PTV AG

241

Chapter 5: User model PrT

LOS

volume/saturation flow rate

0.000 - 0.600

0.601 - 0.700

0.701 - 0.800

0.801 - 0.900

0.901 - 1.000

>1.000

Step 14: Mean queue length calculation per lane group


Queue lengths are also calculated by the HCM 2000 method. In HCM 2010, the method differs.
For this description, please refer to section 31-4, page 31-67 et seqq.
The equation for the calculation of the mean queue length is as follows:
Q = Q1 + Q2

where
Q

mean queue length maximum distance measured in vehicles the queue extends on
average signal cycle

Q1

mean queue length for uniform arrival with progression adjustment

Q2

incremental term associated with random arrival and overflow to next cycle

Step 14a: Calculation of the number of residual vehicles after cycle 1


Q1 represents the number of vehicles that arrive during the red stages and during the green
stages until the queue has dissipated.
vi C
g
------------ 1 ----i
3600
C
Q 1 = PF2 ---------------------------------------------gi
1 min ( 1, X i ) ---C

where
PF2

progression factor 2

vi

volume of lane group i per lane

C
gi

cycle time

Xi

volume/capacity ratio of lane group i

effective green time of lane group i

1 R g----i 1 v----i
P C

s i
PF2 = ---------------------------------------------------- 1 g----i 1 R v----i
P s

C
i

242

PTV AG

Chapter 5.5: Impedances at node

where
PF2

progression factor 2

vi

volume of lane group i per lane

C
gi

cycle time

si

saturation flow rate for lane group i

RP

platoon ratio based on lookup table for arrival type

effective green time of lane group i

Step 14b: Calculate second-term of queued vehicles, estimate for mean overflow queue
Q b 2 8 k i X i 16 k Q b
Qb
Q 2 = 0.25 c i T ( X i 1 ) + ----------- + X i 1 + ----------- + --------------------- + ------------------------
2
ci T
ci T
c i T
(c T )
i

where
T
k
Qb

Analysis period (usually 0.25 for 15 minutes)

ci

capacity for lane group i

adjustment factor for early arrival


initial queue at start of period (default 0)

k = 0.12 I (sigi / 3,600) 0.7 for fixed-time signal


k = 0.10 I (sigi / 3,600) 0.6 for demand-actuated signal
I

upstream filtering factor (set to 1 for isolated intersection)

Step 15: Calculation of the queue length percentile


After calculating the mean back of queue, the percentile of the back of queue is calculated as
follows:
Q------

P3
Q % = Q P1 + P2 e

where
Q
percentile

PTV AG

average queue length

pre-timed signal

actuated signal

70%

P1

P2

P3

P1

P2

P3

85%

1.2

0.1

1.1

0.1

40

90%

1.4

0.3

1.3

0.3

30

95%

1.5

0.5

1.4

0.4

20

243

Chapter 5: User model PrT

percentile

pre-timed signal

98%

1.6

1.0

actuated signal
1.5

0.6

18

1.7

1.5

1.71.7

1.0

13

Saturation flow rate adjustment factors


We now return to the calculation of the saturation flow rate (see "Saturation flow rate
calculation by lane group" on page 236) which involves several adjustment factors.

Step 6 a: Calculate lane width adjustment factor


fw = 1 +

(W 12 )
30

where
fw

lane width adjustment factor

mean lane width ( 8) (ft)

This method differs in HCM 2010. For a description, please refer to HCM 2010, page 18-36.

Step 6b: Calculate heavy goods vehicle factor


f HV =

100
100 + % HV (ET 1)

where
fHV

adjustment factor for heavy goods vehicles

%HV
EP

percentage of HGV per lane group


passenger car equivalent factor (2.0 / HV)

Step 6c: Calculate approach grade adjustment factor


fg = 1

%G
200

where
fg

adjustment factor for approach grade

%G

approach grade as percentage (-6 % to +10 %)

Step 6d: Calculate parking adjustment factor


fP is calculated as follows:

18 N m
N 0.1 -----------------3600 f = -----------------------------------------N

244

PTV AG

Chapter 5.5: Impedances at node

where
fp

parking adjustment factor (1.0 if no parking, otherwise 0.050)

N
Nm

number of lanes in lane group


number of parking maneuvers per hour (only for right turn lane groups) (0 to 180)

In Visum, enter fP which is calculated by the formula, as attribute ICA parking directly at the
node leg.

Step 6e: Calculate adjustment factor for position to city center


fa = 0.9 if link is in the city center (CBD), otherwise 1.0

where
fa

adjustment factor for position

CBD

indicates a central business district

Step 6f: Calculate bus stop blocking factor

f bb

14.4 N
N ----------------------B3600
= --------------------------------N

where
fbb

bus stop blocking adjustment factor ( 0.05)

N
NB

number of lanes in lane group


number of bus stop events per hour (does not apply to left turn lane groups) (0 to 250)

In Visum, enter fbb which is calculated by the formula, as attribute ICA bus blockage directly
at the node leg.

Step 6g: Calculate lane utilization adjustment factor


vg
f Lu = --------------vg 1 N

where
fLu

adjustment factor lane utilization

vg

unadjusted (input) volume for lane group g

vgl

unadjusted (input) volume for lane with highest volume in lane group (veh per hour)

For this adjustment factor, an HCM lookup-table is regarded (HCM 2000: table 10-23 on page
10-26; HCM 2010: table 18-30 on page 18-77). Alternatively, lane attribute values can be used
(ICA user-defined utilization share and ICA use user-defined utilization share).

PTV AG

245

Chapter 5: User model PrT

Step 6h: Calculate right turn adjustment factor


1.0 - (0.35) P RT for single lane approach

or

= 0.85
for exclusive right turn lane

or
1.0 - (0.15) P
RT for shared right turn lane

f RT

where
fRT

right turn adjustment factor ( 0.05)

PRT

proportion of right turn volume for lane group

The calculation according to HCM 2010 differs. For shared lanes, the adjustment factor is no
longer explicitly calculated. For more details, please refer to HCM 2010, page 18-38.

Step 6i: Calculate left turn adjustment factor


The left turn adjustment factor is the most complex of the factors. Here, HCM 2000 and HCM
2010 differ significantly. For the description, please refer to HCM 2010, page 18-38 and pages
31-30 to 31-37.
The calculation is simple for protected left turns. However, if there is permitted phasing, then
the equation is quite complex. It is as follows:

f LT

0.95 for exclusive left turn lane (protected phasing)

= ------------------------------------- for shared left turn lane (protected phasing)


1.0 + 0.05 P LT

see equations below for permissive phasing

where
fLT

adjustment factor for left turns

PLT

proportion of left turn volume for lane group

For permitted staging, there are five cases. When there is protected-plus-permitted staging or
permitted-plus-protected staging, the analysis is split into the protected portion and the
permitted portion. The two are analyzed separately and then combined. Essentially this means
treating them like separate lane groups. Refer to the HCM for how to split the effective green
times among the protected and permitted portions.
1. Exclusive lane with permitted phasing use the general equation below
2. Exclusive lane with protected-plus-permitted phasing use 0.95 for the protected portion
and the general equation below.
3. Shared lane with permitted phasing use the general equation below
4. Shared lane with protected-plus-permitted phasing use the equation above for protected
phasing portion and the general equation below for the permitted portion
5. Single lane approach with permitted left turns use the general equation below

246

PTV AG

Chapter 5.5: Impedances at node

The general equation for calculating fLT for permitted left turns is below. Note that this is not the
exact HCM 2000 equation since there are a few different versions depending on the situation
shared/exclusive lane, multilane/single lane approach, etc. But the equation is similar
regardless of the situation. This general equation is the equation for an exclusive left turn lane
with permitted phasing on a multilane approach opposed by a multilane approach.
The equation is basically the percentage of the time when lefts can make the turn times an
adjustment factor. The adjustment factor is based on the portion of lefts in the lane group and
an equivalent factor for gap acceptance time that is based on the opposing volume. The
calculation of the percentage of the time when lefts can make the turn is a function of the
opposing volume and their green time. The equation is as follows:
gu
1
f LT = ----- --------------------------------------------
g 1 + P L ( E L 1 1 )

( f LTmin f LT 1 )

fLTmin = 2 (1 + PL) / g
(N 1) g
P L = 1 + ----------------------------------------g u ( E L 1 + 4.24 )
gu = g - gq (if gq 0, else gu = g)
v olc qr o
-t
g q = ---------------------------------------------------------------0.5 [ v olc ( 1 qr o ) g o ] l

where

PTV AG

fLT

Global adjustment factor for left-turns

fLTmin

Minimum value for adjustment factor

g
gu

Effective non-protected green time for left-turn lane group

PL

Share of left-turns using lane L

EL1

Through equivalent for non-protected left-turns (veh/hr/lane) (look-up value depends on


conflict flow volume)

gq

Effective non-protected green time, while left-turns are blocked completely and the spill-back
of the conflict flow is reduced

go

Effective green time for conflict flow

N
volc

Number of lanes in lane group

No

Number of lanes in the lane group of the conflict flow

vo

Corrected conflict flow

fLUo

Lane utilization factor for conflict flow

qro

Opposing queue ratio = max[1 - Rpo (go / C), 0] (Rpo = look-up value depends on ArrivalType)

tl

Loss time for left-turn lane group

Effective non-protected green time for left-turns crossing a conflicting flow

vo C
3600 N o f LU

Corrected conflict flow per lane per cycle = --------------------------------------o

247

Chapter 5: User model PrT

The opposing volume is calculated from the signal groups that show green while the subject
lane group has green. To calculate the opposing volume for a subject lane group, the entire
opposing volume is used even if there is an overlap.
The permitted left movement calculation does not need to be generalized to 4+ legs since only
one opposing approach is allowed. If more than one opposing approach is coded, an error is
written to the log file.

Step 6j: Calculate pedestrian adjustment factors for left and right turns
The computation of the factors for left-turning and right-turning pedestrians and bicyclists is a
considerably complex operation. It is performed in four steps. For the computation, the bicycle
volumes of the legs are regarded and the pedestrian volumes of the crosswalks. A traffic flow
has potential conflicts with two crosswalks on the outbound leg. These two crosswalks head for
the opposite directions.
Note: At a leg which is a channelized turn no conflicts occur between right turn movements
and pedestrians.
Step 1: Determination of the pedestrian occupancy rate OCCpedg.

The pedestrian occupancy rate OCCpedg is derived from the volume. The following applies:

1
C
2
C
v pedg = min 5000, v ped -----1 + v ped -----2

gp
gp
v pedg 2000, if v pedg 1000
OCC pedg =
0.4 + v pedg 10000, else

Here, vpedg is the pedestrian flow rate, v1pedg and v2pedg are the pedestrian volumes of the
crosswalks, C is the cycle time of the signal control and g1p and g2p indicate the duration of
the green for the pedestrians.
Note: In the HCM2000 it is implicitly assumed, that the green for the left turn movements
and the green for the pedestrians start at the same time. In Visum, this is not the case,
however. Thus, the following distinction of cases applies in Visum: If the pedestrian green
time overlaps (or touches) the green or amber stage for vehicles, an existing conflict is
assumed. In this case, the duration of the green of the pedestrian signal group is fully
charged. Otherwise it is assumed, that there is no conflict. In this case, gp = 0 is assumed.
Step 2: Determination of the relevant occupancy rate of the conflict area OCCr

Here, three cases are distinguished:

Case 1: Right turn movements without bicycle conflicts or left turn movements from
one-way roads

In this case, the following applies:


OCCr = OCCpedg

Decisive for left turns from one-way roads is, that there is no opposite vehicle flow.

248

Case 2: Right turn movements with bicycle conflicts

PTV AG

Chapter 5.5: Impedances at node

Here, straight turns of bicyclists are assumed.


C
v bicg = min(1900, v bic ----)
g
OCCbicg = 0.02 + vbicg / 2700
OCCr = OCCpedg + OCCbicg - (OCCpedg)(OCCbicg)

Here, vbicg is the bicycle flow rate, vbic is the bicycle volume, C is the cycle time of the signal
control, g is the effective green time of the lane group, and OCCbicg is the conflict area's
occupancy rate caused by bicyclists.

Case 3: Other left turn movements

These are left turn movements which do not originate from a one-way road. Here, a
distinction of cases is made for the values gq and gp. gq is the clearing time of the vehicle
flow on the opposite leg, and gp is the green time for the conflicting pedestrians. The
following applies:
gp = max(g1p, g2p)

Case 3a: gq gp

In this case, the calculation is shortened and the following applies


fLpb = 1.0

Pedestrians and bicyclists are irrelevant here, since the left turn movements have to wait
until the vehicle flow on the opposite leg is cleared.

Case 3b: gq < gp

The following applies:


gq
OCC pedu = OCC pedg 1 0.5 -----
gp
OCC r = OCC pedu [ e

( 5 3600 ) v 0

Here, OCCpedu is the occupancy rate of pedestrians after the clearance of the vehicle flow
on the opposite leg, and OCCpedg is the pedestrians occupancy rate.
Step 3: Determination of the adjustment factors for pedestrians and bicyclists on permitted
turns ApbT

Here, two cases are distinguished with regard to the values Nturn which is the number of
lanes per turn and Nrec, which is the number of lanes per destination leg.

Case 1: Nrec = Nturn

Here applies ApbT = 1 - OCCr

Case 2: Nrec > Nturn

Here, vehicles have the chance to give way to pedestrians and bicyclists. The following
applies:
ApbT = 1 - 0.6 OCCr

PTV AG

249

Chapter 5: User model PrT

Step 4: Determination of the adjustment factors for the saturation flow rates for pedestrians
and bicyclists fLpb und fRpb.

fLpb is the adjustment factor for left turns, and fRpb is the adjustment factor for right turns.
The following applies:
fRpb = 1 - PRT (1 - ApbT) (1 - PRTA)
fLpb = 1 - PLT (1 - ApbT) (1 - PLTA)
PRT and PLT represent the proportions of right turn and left turn movements in the lane
group, and PRTA and PLTA code the permitted shares in the right and left turn movements
(each referring to the total number of right turn and left turn movements of the lane group).

5.5.3.3

Two-way stop nodes

Notes: For the description of this control type, please refer to HCM 2000, chapter 17, in HCM
2010 refer to chapter 19. In most instances, the calculation complies with HCM 2000.
Especially the explicit U-turn handling has been added.
In Visum, two-way nodes are modeled by the control types two-way stop and two-way
yield. In the HCM, the description refers to two-way stop nodes. Basically, the computation
is the same. The only difference is the determination of wait times in step 8.
Nodes of the signalized control type are also calculated according to the method for yieldcontrolled nodes, if no SC has been allocated or the SC has been turned off.
The two-way stop analysis method is based on the gap acceptance theory. The basic idea is
to calculate potential capacities for all movements, and then subtract capacity from these
movements based on movement rank (priority). The calculation flow chart looks like displayed
in illustration 62.

250

PTV AG

Chapter 5.5: Impedances at node

Inputs
Geometry
Volumes
%HGV, Ped Vol

Gap & Follow-Up


Times
Basics
Adjustment Factors

Volume
PHF
Identify Conflicts

Potential Movement
Capacity

Capacity Analysis
Delay, LOS, Queues

Illustration 62: Method of calculation at two-way stops

If you use the HCM 2000 operations model for two-way stop nodes, the Visum attributes in
table 73 will have an effect. Make sure that they are set to realistic values prior to running the
analysis.
Network objects

Attribute

Description / Effect

Link

Share of HGV

HGV share is used in the steps 3 + 4. A value which applies


to all turns originating from this link.

Link

Slope

Used in step 3

Node

ICA peak hour factor


volume adjustment

Factor for the initial volume adjustment to peak volume;


volumes are divided by both node and turn adjustment
factors

Geometry

All

Geometry data of lanes, lane turns and crosswalks

Turn

ICA peak hour factor


volume adjustment

Factor for the initial volume adjustment to peak volume;


volumes are divided by both node and turn adjustment
factors

Turn

ICA Preset critical gap Critical gap value of your choice

Turn

ICA Use preset critical


gap

Optionally, you can overwrite the critical gap, used in step 3


Activate this option, to use the critical gap set.

Turn

ICA Preset follow-up


time

Follow-up time value of your choice

Table 73: Input attributes for the calculation of two-way stops

PTV AG

251

Chapter 5: User model PrT

Network objects

Attribute

Turn

ICA Use preset follow- Optionally, you can overwrite the follow-up time, used in step
up time
4
Activate this option, to use the follow-up time set.

Description / Effect

Lane

ICA Preset critical gap Critical gap value of your choice

Lane

ICA Use preset critical


gap

Optionally, you can overwrite the critical gap, used in step 3.


The analogous value of the turn is not used.
Activate this option, to use the critical gap set.

Lane

ICA Preset follow-up


time

Follow-up time value of your choice

Lane

ICA Use preset follow- Optionally, you can overwrite the follow-up time, used in step
up time
4. The analogous value of the turn is not used.
Activate this option, to use the follow-up time set.

Table 73: Input attributes for the calculation of two-way stops

Output is available through the same attributes as for signalized nodes (table 72). Additionally,
the calculated critical gap and follow-up time data is provided.
The method works with movements (Left, Through and Right) at each approach. Each
movement is ranked according to table 74.
Rank
1

Major Through
Major Right
Pedestrian passage minor flow

Major Left
Minor Right
Pedestrian passage major flow
Major Left priority to gaps in the opposing flow
Minor Right priority to gaps in the flow of the right-most lane of the major flow
Pedestrians Priority to any other flow

Minor Through

Minor Left

Table 74: Ranking of movements

Note: HCM 2010 also regards U-turns on major flows. They are given rank 2. If the calculation
is based on HCM 2010, the U-turn related setting in the procedure parameters will not affect
these U-turns.

Step 1: Flow rate (volumes) calculation for each movement


The 15 min peak flow rates (as calculated from the PHF adjustment) are used as the adjusted
movement volumes.

Step 2: Conflicting flows for each movement


In addition to calculating the volumes for each movement, the conflicting volumes for each
movement for each approach must be calculated.

252

PTV AG

Chapter 5.5: Impedances at node

Notes: Rank 1 movements do not have conflicting flows since they have the highest priority.
Mainly, rank 1 movements are excluded from the analysis, with the exception of one
additional evaluation (see "Calculation of the critical vol/cap ratio for the entire intersection"
on page 238).
According to HCM 2010, pocket lanes for left turns (rights for left-hand traffic accordingly) in
the major flow are dealt with separately.
Only nodes with three or four legs are described in the HCM. In Visum, also multi-leg nodes
can be calculated. The 'Uncontrolled' rule is applied to conflicting flows between minor legs
which are not separated by a major leg.
For left-hand traffic, the right-hand calculation is performed symmetrically.
For right-hand traffic, the following example models the conflict flow of a left turn on a major
flow:

Volume through traffic in opposing direction + volume right turns in opposing direction
(does not apply, if right turns in opposing direction are separated by a channelized turn and
need to attend a yield sign or a stop sign) + pedestrian volumes minor flow crossing

The table 75 shows the equations for conflicting volumes.


Movement

Conflicting flows

Major Left

OT + OR* + ToP

Minor Right

JT/N + 0.5JR* + FrP + ToP

Minor Through

2JL + JT + 0.5JR* + FrP + ToP + 2JLF + JTF + JRF*

Table 75: Calculation of the conflicting volumes

where
O

Opposite direction

Through

Right

Left

Number of through lanes

Major

Minor

Far (for minor through/left turns the second major flow encountered)

ToP

Approach (to) with pedestrian crosswalk

FrP

Exit (from) with pedestrian crosswalk

There is a number of cases where the conflicting volume is adjusted:

PTV AG

If the major flow (right) is separated by a channelized turn and needs to attend a yield sign
or a stop sign then this flow will not be considered in the conflicting volume calculation for
other flows..
If the major flow has more than one lane, only the right lane volume of the major flow (= vol
/ num through lanes) applies as conflicting, for minor right and minor left turns.
If the major flow has a right turn lane, then the right turns of the major flow do not count for
the conflicting volume.

253

Chapter 5: User model PrT

For left turns from the minor flow, the right turn volume of the opposing direction does not
count for the conflicting flow, if the destination link of the two turns has more than one lane.

Notes: Apart from the U-turns, the HCM 2010 differs from HCM 2000 in subtle differences.
For the determination of conflicting flows, please refer to HCM 2010, pages 19-9 to 19-14.
The HCM does not regard bending two-way stop/yield cases. In this case, conflicting flows
are determined according to Brilon and Weinert, 2002.

Step 3: Critical gap calculation for each movement


The critical gap is the time an average driver would accept in order to merge with traffic.

Example
Sarah needs 4 seconds of space between vehicles to make her left turn and merge with other
traffic safely.
The critical gap equation is:
tcx = tcb + (tcHVPHV) + (tcGG) - tcT - t3LT

where
tcx

critical gap for movement x

tcb

base critical gap (see table 76)

tcHVPHV

adjustment factor for heavy vehicles percent heavy vehicles

tcGG

adjustment factor for grade grade (as a decimal)

tcT

two stage adjustment factor (currently set to 0 for one stage modeling)

t3LT

Critical gap adjustment factor for geometry

The other adjustment factors are:


tcHV = 1, for two - lane major street
2, for four - lane major street

0.1, for minor right

tcG = 0.2, for minor left and through


1, otherwise

t3 LT = 0.7 , for minor left at T - intersection

0, otherwise

The base values for the critical gap are calculated as shown in table 76.
Movement

Base critical gap value tcb


< 4 lanes major flow

4 + lanes major flow

Major Left

4.1

4.1

Minor Right

6.2

6.9

Minor Through

6.5

6.5

Minor Left

7.1

7.5

Table 76: Base values for the critical gap

254

PTV AG

Chapter 5.5: Impedances at node

If the calculated values differ from the observed values, manually set values per turn can be
used.

Step 4: Follow-up time calculation for each movement


The follow-up time is the extra time needed for a second car to also take the gap.

Example
Suppose Frank was waiting behind Sarah in the intersection. If he turns just after Sarah, he
would need a follow-up time of 2 seconds, rather than another 4 seconds to be able to merge
safely with other traffic. So, if the gap between vehicles was at least 6 seconds, both Sarah and
Frank could safely make their turns.
The follow-up time equation is:
t fx = t fb + t fHV P HV

where
tfx

follow-up time for movement x

tfb

base follow-up time (table 77)

tfHVPHV

follow-up time adjustment factor for heavy vehicles percent heavy vehicles

The other adjustment factors are:


0.9 for two-lane major street
t fHV =
1.0 for four-lane major street

Follow-up times are calculated according to table 77.


Movement

Base follow-up time value tfb

Major Left

2.2

Minor Right

3.3

Minor Through

4.0

Minor Left

3.5

Table 77: Follow-up times

If the calculated values differ from the observed values, manually set values per turn can be
used.

Step 5: Calculate the potential (or ideal) capacity for each movement
The potential capacity is the capacity which is achieved if this movement uses all potential
gaps (i.e. no higher ranking movements take up the gaps). Furthermore, it is assumed that
each movement is made from an exclusive lane. The potential capacity is defined as follows:
e (vcxtcx 3600 )
c px = vcx
1 e vcxt fx 3600

PTV AG

255

Chapter 5: User model PrT

with
cpx

potential capacity for movement x (veh/hr)

vcx

conflicting flow for movement x (conflict/hr)

tcx

critical gap for movement x

tfx

follow-up time for movement x

Step 6: Calculate movement capacity taking into account impedance effects


Higher ranking movements impede lower ranking movements capacities since vehicles
making higher ranked turns can use the available gap space before the lower ranked
movements. Therefore, we adjust the potential capacity by an adjustment factor to yield the
movement capacity. The movement capacity equation is as follows:
c mx = c px

i Movements with greater rank than movement x

p vi

j Impeding pedestrian movements

p pj

where
cmx

movement capacity for movement x (veh/hr)

cpx

potential capacity for movement x (veh/hr)

pvi = 1

P pj

vi
cmi = probability impeding vehicle movement i is not blocking subject movement

wv j ----SP
= 1 ---------------- = probability impeding ped movement j is not blocking subject movement
3600

vi

volume movement i

vj

volume pedestrian flow j (peds/hr)

w
SP

lane width (ft), standard value 12 ft.


pedestrian walking speed (ft/s), standard value is 4 ft/s

Since the calculation depends on higher rank movement capacities the calculation proceeds
from the top down (from rank 1 to rank 4 movements). Impeding vehicle and pedestrian
movements for each subject movement are listed in table 78:
Movement

Rank

Impeding movements

Major Through

None

Major Right

None

Major Left

ToP

Minor Right

FrP, ToP

Minor Through

JL, JLF, FrP, ToP

Minor Left

JL, JLF, OT, OR, FrP, ToP

Table 78: Impeding movements

256

PTV AG

Chapter 5.5: Impedances at node

where
J

Major

Minor

Opposite direction

Through

Right

Left

Far (for minor through/left turns the second major flow encountered)

ToP

Approach (to) with pedestrian crosswalk

FrP

Exit (from) with pedestrian crosswalk

Step 6a: Calculate adjustment for impeding major left turns


There is also an adjustment factor for major left if it does not operate from an exclusive lane.
The equation uses a default saturation flow rate. It is as follows:
1 p vJL
p vJL' = 1 ------------------------------------v JT v JR
1 ------+ -------s JT s JR
where
pvJL

modified probability of impeding maJor left

pvJL

unmodified probability of impeding maJor left

vJT

volume major through

vJR

volume major right (0 if exclusive right turn lane)

sJT

sat flow major through (1700 standard)

sJR

sat flow major right (1700 standard)

Note: Please refer to HCM 2010 page 19-20, for the description of a short pocket lane on the
major flow scenario.

Step 6b: Calculate adjustment for minor left turns


In addition, there is a special adjustment for minor lefts (rank 4). The equation is below.
Basically the major lefts and the minor through is precalculated and then adjusted. The
adjusted value is then used in conjunction with the remaining minor right and pedestrian
probabilities.
p

ii

= p vJL p vJLF p vIT


ii

i
ii
ii
p
p = 0.65 p --------------+ 0.6 p
ii
p +3
i

p vR 4 = p p vIR p pIP p pJP

where

PTV AG

257

Chapter 5: User model PrT

pvJL

probability of impeding maJor left near

pvJLF

probability of impeding maJor left far

pvIT

probability of impeding minor through

pvR4

probability minor left (rank 4)

pvIR

probability minor right (rank 2)

ppIP

probability minor pedestrian

ppJP

probability major pedestrian

Step 7: Capacities for movements that share lanes


The calculations so far assume that each minor movement operates out of an exclusive lane.
When there is a shared lane, a combined capacity is calculated for those movements which
share a lane.
CSH =

vi

c i

where
CSH

shared lane capacity

vi

volume minor street movement i

cm

movement capacity minor street movement i

Note: Note that the upstream signal and platoon flow adjustments are currently omitted from
the calculation. The same applies for the two-stage gap acceptable adjustment, as well as for
the flared approach adjustment.

Step 8: Calculate delay


The calculation of control delay is defined as follows:
vx
3600
------------- ------2
v
c
c
v
x
x
mx
mx
d x = 3600
------------- + 900 T ------- 1 + ------- 1 + -------------------------- +5
c

c mx
c mx
450 T
mx

where
dx

mean delay per vehicle for movement x

cmx

capacity for movement (shared lane x, CSH)

T
vx

duration of analysis period (hr) (default 0.25 for 15 min)


movement volume (shared lane x, VSH)

A similar formula is used for the calculation of either two-way control type (yield or stop):

258

PTV AG

Chapter 5.5: Impedances at node

vx
3600
------------- ------vx
vx
c mx c mx
vx
3600

d x = ------------- + 900 T -------- 1 + -------- 1 + --------------------------- + 5 min --------, 1


c mx
c mx
c mx
c mx
450 T
2

Control delay per movement is aggregated to approach with a weighted (by volume) mean of
all approach movements/shared lanes. Mean approach delay is then aggregated to the entire
intersection with a weighted mean as well. The equations are the same as the ones for
signalized intersections.
Note that rank 1 movements get no delay. If, however, there is no exclusive left turn pocket,
then rank 1 movements may experience delay. There is therefore, an additional delay equation
for rank 1 movements when there are no left turns pockets on the major approaches. The
equation is as follows:

dR 1

v
( 1 p vJL ) d JL ----TN
----------------------------------------------if N > 1
=
vT + vR

(1 p ) d
if N = 1
vJL
JL

(5)

where
dR1

delay rank 1 vehicles (s/veh)

N
pvJL

number of through lanes per direction of the major flow

dJL

delay to major left (s/veh)

vT

shared through lane volume (for multilane sites, only the volume in the shared lane)

vR

shared right turn lane volume (for multilane sites, only the volume in the shared lane)

probability for an adjustment factor impeding major left (5)

This delay is then substituted by the zero delay of rank 1 movements when calculating
approach and/or intersection delay.

Step 9: Level of Service


Level of Service is then simply defined as displayed in table 79 based on intersection delay.
LOS

Mean delay/vehicle

0 10 sec.

10 15 sec.

15 25 sec.

25 35 sec.

35 50 sec.

50 + sec.

Table 79: Allocation of a LOS to the mean delay per vehicle

PTV AG

259

Chapter 5: User model PrT

Note: For LOS analyses, HCM 2010 additionally takes into consideration whether the
capacity was exceeded. If this is the case, always level F of service will be allocated (HCM
2010, page 19-2).
The intersection queue length calculation is:

Q 95 x

3600 v x
------------- -------2
c mx
v
c mx c mx
vx
x
= 900 T -------- 1 + ------- 1 + -------------------------- ------------

3600
c mx
c mx
150 T

where
Q95x

queue length 95th percentile for movement x (veh)

cmx

capacity for movement (shared lane x, CSH)

T
vx

duration of analysis period (hr) (default 0.25 for 15 min)

5.5.3.4

movement volume (shared lane x, VSH)

All-way stop

Note: For the description of this control type, please refer to HCM 2000, chapter 17, in HCM
2010 refer to chapter 20. The calculations described in HCM 2010 and HCM 2000 are
identical.. HCM 2010 additionally includes the guidelines for queue length calculations (HCM
2010, page 20-17), which is missing in HCM 2000. Furthermore, the volume/capacity ratio is
regarded for the LOS calculation. In case of overload, automatically level F is assigned.
The HCM 2000 All-Way stop controlled (AWSC) capacity analysis method is an iterative
method. The model looks at all possible scenarios of a vehicle either being at an approach or
not being at an approach. Based on the input volumes the probability of each scenario
occurring is calculated as well as the mean delay. The v/c ratio is calculated for each scenario
which in turn impacts the others. Therefore, an iterative solution is needed to find the capacity
of each approach.
Unlike the signalized method, which works with signal groups, or the TWSC method, which
works with movements, the AWSC model works with lanes by approach.
The basic calculation is described in the flow chart in illustration 63. The user inputs
intersection geometry and volumes, along with a couple of additional attributes such as PHF
and %HGV. The volumes are adjusted and allocated to the lanes. The next step is to calculate
the saturation (capacity) follow-up time adjustment factors. Then the departure follow-up times
(i.e. the mean time between departures for a lane at an approach) are calculated based on all
the combinations of the probability states. This departure follow-up time for each lane for each
approach is dependent on the other approaches and so it is calculated in an iterative manner.
Once a converged value is found, then the service time, mean delay and LOS can be
calculated.

260

PTV AG

Chapter 5.5: Impedances at node

Inputs
Geometry
Volum es

Volume
PHF
Lane volumes

Base Headway
Adjustments

Probability States

Departure H eadway

Final D egree of
Utilization

Service Time and


C apacity
Delay and LOS

Illustration 63: Calculation process for an All-Way stop node

If you use the HCM operations model for All-Way stop nodes, the following Visum attributes in
table 80 will have an effect. Make sure that they are set to realistic values prior to running the
analysis.
Network object

Attribute

Description / Effect

Link

ShareHGV

Proportion of heavy goods vehicles, used in follow-up times


adjustment. A value which applies to all turns originating from this
link.

Node

ICAPHFVolAdj

Initial volume adjustment to peak period. Then, volumes are divided


by both node and turn adjustment factors.

Geometry

All

Geometry information on lanes, lane turns and crosswalks

Turn

ICAPHFVolAdj

Initial volume adjustment to peak period. Then, volumes are divided


by both node and turn adjustment factors.

Table 80: Input attributes for an All-Way stop node

Output is available through the same attributes as for signalized nodes (table 71).

PTV AG

261

Chapter 5: User model PrT

The first step is to PHF adjust the volumes by lane by movement by approach. In addition the
% heavy goods vehicles by lane by movement by approach are also input if available. Since in
Visum volumes are specified by movement and not by lane by movement, they are first
disaggregated per lane according to a standard method.
The next step is to calculate the follow-up time adjustment factors for each lane. The
calculation applies as follows:
hadj = hLTadj pLT + hRTadj pRT + hHVadj pHV

where
hadj

follow-up time adjustment

hLTadj

follow-up time adjustment for left turns

hRTadj

follow-up time adjustment for right turns

hHVadj

follow-up time adjustment for heavy vehicles

PLT

proportion of left-turning vehicles on approach

pRT

proportion of right-turning vehicles on approach

pHV

proportion of heavy vehicles on approach

The adjustment factors are listed in table 81.


Number of lanes of the subject approach

Adjustment factor

Saturation

Mean follow-up time

LT

RT

HV

0.2

-0.6

1.7

0.5

-0.7

1.7

Table 81: Adjustment factors

After calculating the follow-up time adjustment factor the departure follow-up time is calculated
in an iterative manner. It involves five steps.

Step 1: Calculate combined probability states probability


P( i) =

j P ( a j )

where
P(i)
P(aj)

probability for combination i

aj

1 or 0 depending on lane type j (see table 82)

probability of degree-of-conflict (DOC) for combination i lane type j

This probability states calculation has a few parts. For each lane type j the P(aj) is calculated.
P(aj) is calculated based on a lookup table (table 82).

262

PTV AG

Chapter 5.5: Impedances at node

aj

Vj (volume conflicting approach)

P(aj)

>0

Xj

>0

1 - Xj

Table 82: Probability states calculation of degree-of-conflicts

Notes:
If iteration is 1, then Xj = (Vj hd) / 3,600

If iteration is > 1, then Xj = min(1,(Vj hd) / 3,600)

Initial value hd = 3.2 s

Value aj is taken from the DOC table (table 83). This table contains all the combinations of 0
and 1 per lane for each approach. For two lanes per approach it looks like displayed in table 83
(see exhibit 17-30 in the HCM 2000 for the full table).
i

DOC case (Ck)

Number of
vehicles

Oppsoing
approach
L1

Left
(subject approach)

Right
(subject approach)

L2

L1

L2

L1

L2

64

There are 64 combinations for 4 legs each with 2 lanes.

Table 83: Excerpt from the DOC table for two lanes per approach

The combined probability states probability P(i) is then calculated for each row (i) for each
column (lane type) (j). To calculate P(i) we take the product of all probabilities of each opposing
lane and each conflicting lane P(aj). The result P(i) = P(aj) is the probability state for row (i).

Step 2: Calculate probability state adjustment factors


After calculating P(i) for each case (i), an adjustment for each DOC case needs to be
calculated. The adjustment accounts for serial correlation in the previous calculation due to
related conflict cases. For DOC case (Ck), the adjustment equations are:

PTV AG

263

Chapter 5: User model PrT

P( C1 ) = P( 1 )
4
P( C2 ) = P( i )
2
10
P( C3 ) = P( i )
5
37
P( C4 ) = P( i )
11
64
P( C5 ) = P( i )
38
adjP( C1 ) = a [ P( C2 ) + 2 P( C3 ) + 3 P( C4 ) + 4 P( C5 )] / n
adjP( C2 ) = a [ P( C3 ) + 2 P( C4 ) + 3 P( C5 ) P( C2 )] / n
adjP( C3 ) = a [ P( C4 ) + 2 P( C5 ) 3 P( C3 )] / n
adjP( C4 ) = a [ P( C5 ) 6 P( C4 )] / n
adjP( C5 ) = a [ 10 P( C5 )] / n
where
a
n

0.01 (or 0.00 if no serial correlation)


number of non-zero cases (i) for each DOC case (at most n = 1 for C1, 3 for C2, 6 for C3, 27 for
C4 and C5)

Step 3: Calculate adjusted probability


P(i) = P(i) + adjP(i)

where
P(i)
P(i)
adjP(i)

adjusted probability for case i


probability of degree-of-conflicts for case i
probability adjustment factor case i

Step 4: Calculate saturation follow-up time


hsi = hadj + hbase

where
hsi

saturation follow-up time by DOC case i

hadj

follow-up time adjustment by lane

hbase

base follow-up time by DOC case i

For each DOC case i, the base follow-up time hbase is taken from a lookup table which is based
on the particular DOC case (1 5) and geometry group (table 84).

264

PTV AG

Chapter 5.5: Impedances at node

Number of lanes
Subject
approach

Opposing
approach

Conflicting
approach

Intersection type

Geometry group

4 leg or T

4 leg or T

4 leg or T

3a / 4a

3b

4 leg

4b

1-2

1-2

4 leg or T

1*

1*

4 leg or T

4 leg or T

Table 84: Lookup table base follow-up time

Note: * If subject is 3 lanes and either opposing or conflicting approach is 1 lane then
geometry group 5, else geometry group 6.
The model is generalized for 3+ lanes in order to apply it to 4+ leg intersections. The extension
is that these 4+ leg cases are geometry group 6.
The table 85 shows the saturation follow-up time base values.

Geometry group

DOC case

Number of
vehicles (Sum of
the [0,1] for the
case)

1
2
>=3

1
2
>=3

2
3
4
>=5

3
4
5
>=6

3.9

4.7

5.8

7.0

9.6

3.9

4.7

5.8

7.0

9.6

3a

4.0

4.8

5.9

7.1

9.7

3b

4.3

5.1

6.2

7.4

10.0

4a

4.0

4.8

5.9

7.1

9.7

4b

4.5

5.3

6.4

7.6

10.2

4.5

5.0
6.2

6.4
7.2

7.6
7.8
9.0

9.7
9.7
10.0
11.5

4.5

6.0
6.8
7.4

6.6
7.3
7.8

8.1
8.7
9.6
12.3

10.0
11.1
11.4
13.3

Table 85: Base values for the saturation follow-up time

The DOC case is dependent on the 64 types of a 4 leg intersection. Nodes with more than 4
legs are first collapsed to four legs.

PTV AG

265

Chapter 5: User model PrT

Step 5: Calculate departure follow-up time


hd =

i I P' ( i ) hsi

where
hd

departure follow-up time for lane

hsi

saturation follow-up time for each i in I

P(i)
I

adjusted probability for each i in I


Row of table 1

These five steps are repeated until the departure follow-up time values converge (change is <
0.1). Now, the calculated departure follow-up time hd differs from the original value. Thus, the
next iteration will return a different result.
Now that the departure follow-up time for each lane is calculated, service time and capacity can
be calculated. The service time is calculated as follows:
t = hd - m

where
t
hd

Service time

move up time (2.0 s for geometry groups 1-4 and 2.3 s for groups 5-6)

Departure follow-up time

The capacity is calculated as follows: the volume of the subject lane is incremented until its
degree of utilization (vjhd)/ 3,600 is 1.0. The volume of the other approaches is held constant.
At this point, the subject lanes volume value is taken to be the subject lanes capacity.
Capacity is therefore dependent on the input volumes for each approach.
The search for capacity is slow in a linear implementation. Thus a binary search is performed
with an upper bound of 1,800 vphpl.
Mean delay per lane is calculated from the equation below. The weighted mean delay for an
approach is calculated based on lane volume weights. Intersection average delay is calculated
based on the weighted mean by approach volumes. The equations are the same as the ones
for signalized intersections.
hd x
2
d x = t + 900 T x 1 + ( x 1 ) + ----------------+5
450 T

where

266

dx

Mean delay per vehicle for lane x

t
T
x

Service time

hd

Departure follow-up time

Duration of analysis time slot (hr) (default 0.25 for 15 min)

Vh
3600

d
Utility rate -------------

PTV AG

Chapter 5.5: Impedances at node

Level of Service is defined as a lookup based on intersection delay (table 86).


LOS

Mean delay/vehicle

0 10 s

10 15 s

15 25 s

25 35 s

35 50 s

50 + s

Table 86: Determining the LOS based on the mean delay per vehicle

The proposed extension for 4+ legs is to combine multiple lefts or rights into one left or right by
adding the number of lanes together when calculating conflicting flows. For example, when
there are two conflicting lefts for a subject approach, one with one lane and one with two lanes,
they are merged into one conflicting left with three lanes. This allows the existing framework to
be used. It probably slightly understates the delay, but it will work within the existing framework
and will result in additional delay for additional legs.

5.5.3.5

Roundabouts according to the HCM 2010 method

For this analysis method, please refer to HCM 2010, chapters 21 and 33. It is similar to the one
for two-way stop nodes and mainly differs from it in the following points:

Determining the conflict flows follows the geometry of the roundabout.


The standard values for gaps differ due to changed visibility conditions. Also this calculation
is performed on the basis of lanes, not on the basis of turns.
This method is available for one- and two-lane approaches (plus one optional bypass lane).
The Visum method used for three- or multiple-lane approaches is not described in the
HCM. Visum distributes the volume across the lanes as for two-way stop nodes.

The calculation process is illustrated by illustration 64.

PTV AG

267

Chapter 5: User model PrT

In p u ts
V ol um es

Vo lu m e
In co m i ng l eg s
C on flic ting v ol um e s

T im e g a p s
C ri ti c al g aps
F ol l ow -up t im es

C ap a city

W a itin g tim e
Q u eu e l en g th

Illustration 64: Calculation process for roundabouts according to HCM 2010

If you use the HCM 2010 operations model for roundabout nodes, the Visum attributes in
table 87 will have an effect. Make sure that they are set to realistic values prior to running the
analysis.
Network objects

Attribute

Description / Effect

Geometry

All

Geometry data of lanes, lane turns and crosswalks

Node

ICAPHFVolAdj

Turn

ICAPHFVolAdj

Factor for adjustment of initial volumes to peak volumes.


Then, volumes are divided by both node and turn
adjustment factors.

Leg

Center island length

Length of center island

Leg

Center island width

Width of center island

Leg

Channelized turn
length

Length of channelized turn

Leg

Has splitter Island

Indicates whether a leg has a splitter island (yes/no)

Leg

Length of splitter
island

Length of the splitter island


Note
Value entered is used if the Has splitter island attribute is
activated.

Leg

Splitter island width

Wdith of splitter island


Note
Value entered is used if the Has splitter island attribute is
activated.

Leg

Has bypass lane

Indicates whether the leg has a bypass lane (yes/no)

Table 87: Input attributes for roundabout nodes according to HCM 2010

268

PTV AG

Chapter 5.5: Impedances at node

Network objects

Attribute

Description / Effect

Leg

Share of bypass
volume

Proportion of right turns (left-hand traffic: left turns), which


use a bypass lane for the turn movement.
Note
This information is used, if the Has bypass lane attribute is
activated.

Lane

ICA Preset critical gap Critical gap value of your choice

Lane

ICA Use preset critical


gap

Optionally, you can overwrite the critical gap, used in step 4


The analogous value of the turn is not used.
Activate this option, to use the critical gap set.

Lane

ICA Preset follow-up


time

Follow-up time value of your choice

Lane

ICA Use preset follow- Optionally, you can overwrite the follow-up time, used in step
up time
5 The analogous value of the turn is not used.
Activate this option, to use the follow-up time set.

Table 87: Input attributes for roundabout nodes according to HCM 2010

Output is available through the same attributes as for signalized nodes (table 72).
The calculation method according to HCM 2010 consists of twelve consecutive steps. Here,
the description is reduced to the most important steps.

Step 1: Calculate flow rates (volumes) for each turn


The turn volumes are converted by multiplying them with the peak hour factors of the turns and
the node in values for the 15 minute peak.

Step 2: Calculating traffic flows for each lane and conflicting volumes for each
approach
All calculations are based on the traffic flows and conflicting volumes at each approach. These
flows are derived from the turn volumes (in illustration 65 for a roundabout with four
approaches designated with v1 to v12).

PTV AG

269

Chapter 5: User model PrT

Illustration 65: Approaching flows at a four-leg roundabout

For the distribution of the volumes to the lanes please refer to HCM 2010, pages 21-14 and 2115.

Example
The flow from the south is the sum of turn volumes v7 + v8 + v9. The conflicting flow which
applies to this flow is however the sum v1 + v2 + v10. This approach can be applied to
roundabouts with a countless number of approaches. U-turns can also be considered in the
same way, if you want to integrate them in the ICA calculation.
If an approach has more than one lane, the total inflow is distributed on lanes.
1. If only one lane is permitted for left turns, its volume is the sum of all volumes of left turns.
2. If only one lane is permitted for right turns, its volume is the sum of all volumes of right turns.
3. The remaining volume is distributed to all lanes in such way, that they all have the same
volume if possible.

Step 3: Capacity
The capacity of an approach depends on various factors: the number of lanes per approach
and the number of lanes in the roundabout and whether a lane is a bypass lane. For each of
the cases, predefined formulas can be used (HCM 2010, equations 21-1 to 21-7). This is the
basic formula:
c = 1130 e

Bv

Here B equals 0.001 for one-lane and two-lane entry roads to single-lane roundabouts. For
single-lane approaches to two-lane roundabouts B equals 0.0007. Two-lane approaches to
two-lane roundabouts use the following values for B: 0.00075 for the inner-most (let) lane, and
0.0007 for the right lane. For bypass lanes, with one conflicting exit lane, B is assumed to be
0.001. 0.0007 is used if there are two conflicting exit lanes.

270

PTV AG

Chapter 5.5: Impedances at node

Users with detailed knowledge of critical gaps and follow-up times can replace these formulas.
For the control type 'roundabout', critical gap and follow-up time are set by lane. Turn-related
values of this attribute are not regarded. For the extended computation, the capacity is derived
from the following data (HCM 2010, page 33-3):
Bv

c = Ae
------------A = 3600
gap f

gap
gap c -----------f
2B = ---------------------------3600

where
c
v
gapc

capacity in PCU/h

gapf

follow-up time in s

conflicting flow in PCU/h


critical gap in s

Visum uses the following standard values: 4 s for the critical gap and 3 s for the follow-up time.
You can optionally overwrite both values by lane.
Pedestrians have a bearing on the capacity. For a detailed description, please refer to HCM
2010, pages 21-16 and 21-17.
To the turns, the approach capacity is distributed in proportion to the volume. The result is
stored in the turn attribute ICA final capacity.

Step 4: Wait times


The mean wait time on a lane of an approach arises from the following values:
3600
------------ v-2
v
3600
v
c
c + 5 min -v- ,1

d = ------------ + 900 T -- 1 + -- 1 + -----------------c


c
c
c
450 T

d
c
v
T

mean delay in s/PCU


lane capacity in PCU/h
lane volume in PCU/h
observation period in h

The mean delay of a turn is the volume weighted mean of the mean delay of lanes used. The
result is saved in the turn attribute tCur.
Note: For turns with lane turns without allocated signal group, tCur is set to zero.

Step 5: Queue lengths


The mean queue length on a lane of an approach arises from the following values:

PTV AG

271

Chapter 5: User model PrT

Q 95

3600- v-
2 -----------c 3600
v
v
c

= 900 T -- 1 + 1 -- + -------------------- ------------c


150 T
c
c

where
Q95

95% percentile of queue length in PCU

c
v
T

lane capacity in PCU/h


lane volume in PCU/h
observation period in h

The attribute ICABackOfQueueForDefPerc is the maximum of the Q95 percentiles for the
lanes used.

Step 6: Level of Service (LOS)


LOS per lane of an approach is defined as a classification of the mean delay (table 88).
LOS

Mean Delay [s / PCU]

0 - 10

>10 - 15

>15 - 25

>25 - 35

>35 - 50

>50

Table 88: LOS per lane based on the mean delay

The HCM does not determine the calculation of the LOS per approach, turn or node. In these
cases Visum calculates the LOS on the basis of the volume weighted mean delay. If the
volume exceeds the capacity, the LOS is automatically set to F.

5.5.3.6

Roundabouts according to the TRL/Kimber 2010 method

This analysis method regards approach capacity as a function of geometry and the conflicting
volume in roundabouts. On the basis of numerous observations, this function was calibrated to
British roundabouts.
The illustration 66 shows the calculation process for roundabouts according to the TRL/Kimber
method.

272

PTV AG

Chapter 5.5: Impedances at node

Inputs
Geometry
Volumes

Volume
Incoming legs
Conflicting volumes

Capacity

Waiting time
Queue length

Illustration 66: Calculation process for roundabouts according to the TRL/Kimber method

In Visum, the geometry of the roundabout is described through leg attributes. These attributes
are only important, if the node is a roundabout and if TRL/Kimber is selected as analysis
method. In all other cases, the parameters are ignored at ICA calculation. The meaning of the
parameter is illustrated in illustration 67, which has been taken from the DMRB guideline TD
16/93. For a better comparison with this guideline, the common English original attributes and
abbreviations are specified in the tabular overviews. Another parameter describes the
temporal variability of the inflow.

PTV AG

273

Chapter 5: User model PrT

Illustration 67: Description of the node geometry for the TRL/Kimber model

The table 89 shows the additional input attributes at legs for calculation according to TRL/
Kimber.
Name

DMRB definition

ICA inscribed circle


diameter

Value
type

Value range
(Default value)

Meaning

ICAInscribedLength
CircleDiameter (D)

10 - 200 m (40
m)

External diameter of the


roundabout. For
asymmetric roundabouts
specify the radius related to
the environment of the
respective approach.

ICA entry width

ICAEntryWidth (e)

Length

3 - 20 m (7 m)

Width of the entry directly at


roundabout

ICA approach half width

ICAApproachHalfWidth (v)

Length

2 - 15 m (3.5
m)

Road width of the approach


link without pocket

ICA flare length

ICAFlareLength
(L)

Length

1 - 100 m (20
m)

Half length of the approach


between the points where
ICAEntryWidth and
ICAApproachHalfWidth are
measured.

Table 89: Input attributes for calculation according to the TRL/Kimber method

274

PTV AG

Chapter 5.5: Impedances at node

Name

DMRB definition

Value
type

Value range
(Default value)

Meaning

ICA entry radius

ICAEntryRadius (r) Length

1 - 1,000 m (35 Circle radius which


m)
tangentially approximates to
the outer circle of the
roundabout and the outer
boundary of the approach.

ICA entry angle

ICAEntryAngle () Integer

0..180 (45)

ICA grade separation

ICAGradeSeparation (SEP)

Length

0 - 100 m (0 m) Distance between approach


and exit of the same node
leg. For regular
roundabouts specify 0 m.
This implies the roundabout
is not grade-separated.
With values > 0 you
describe the approaches of
grade-separated expanded
roundabouts, where the
entry is far away from the
exit of the same leg.

ICA Kimber Hollis c-factor ICAKimberHollisC

Double

0 .. 10 (1.0)

See illustration 67

In the queue length formula


by Kimber-Hollis, the cfactor describes the
variability of the inflow

Table 89: Input attributes for calculation according to the TRL/Kimber method

These attributes are only important, if the ToNode of the link has the controller type
roundabout, i.e. the link represents an approach to a roundabout. In all other cases the
attributes are ignored.
The output attributes correspond to those for signalized intersections (table 72).

Step 1: Traffic flows and conflicting volumes for each approach


All calculations are based on the traffic flows and conflicting volumes at each approach. These
traffic flows are derived from the turn volumes. All volumes are expressed in PCUs.

Step 2: Approach capacities


For roundabouts with RDistanceExit = 0, the following applies:
k ( F f qc )
Cap =
0

if F > f q c
else

where

PTV AG

Cap
qc

approach capacity in PCU/h

k
F
f

1 - 0.00347 ( - 30 ) - 0.978 [(1/r) - 0.05]

conflicting flow in PCU/h

303 x
0.21 t (1 + 0.2 x)

275

Chapter 5: User model PrT

t
M

1 + 5 / (1 + M)

x
S

v + (e - v) / (1 + 2 S)

e(D - 60)/10
1.6 (e - v) / L

The remaining variable descriptions refer to the attributes of the geometry description.
Different from the above mentioned, the following applies for roundabouts with RDistanceExit
> 0:
Cap =1.004F - 0.036SEP - 0.232 qc + 14.35 - f qc(2.14 - 0.023 qc)

where all sizes as above, however Cap and qc in PCU/min.


The capacity of each lane is distributed proportionally to the volume of the turns. The result is
saved in PCU/h in the turn attribute ICAFinalCapacity.

Step 3: Queue lengths


The queue length of an approach results from the Kimber and Hollis formula (Kimber, Hollis
1979), (Kimber, Daly 1986).
2

( 1 ) ( T ) + ( 1 L 0 )T 2 ( 1 C ) ( L 0 + T )
A = -------------------------------------------------------------------------------------------------------------------------T + 1 C
4 ( L 0 + T ) ( T ( 1 C ) ( L 0 + T ) )
B = -----------------------------------------------------------------------------------------------T + 1 C

1
2
L = --- ( A + B A )
2
where
L

expected queue length at the end of the observation period in PC units

approach capacity in PCar units/h

T
L0

length of the observation period in h

C
v

Variation factor KVKimberHollisC

= v / = Saturation

initial queue length (in Visum always 0)

approach volume in PCar units/h

Visum uses the formula modified in (Kimber, Hollis 79) for increased accuracy.
The mean queue length of each turn is equal to the mean queue length of its approach and is
stored in the turn attribute ICAQueueLength.

Step 4: Delays
The mean control-based wait time per approach results from the Kimber and Hollis formula
(Kimber, Hollis 1979), (Kimber, Daly 1986).

276

PTV AG

Chapter 5.5: Impedances at node

T
1
J = --- ( 1 ) --- ( L 0 C + 2 )
2

L0 + 1
4 T
1
K = --- --- ( 1 ) + --- TC --------------- ( 1 C )
2

1
2
d = --- ( J + K J )
2
where
d

mean permitted delay in the observation period in h

approach capacity in PCar units/h

T
L0

length of the observation period in h

C
v

Variation factor KVKimberHollisC

= v / = Saturation

initial queue length (in Visum always 0)

approach volume in PCar units/h

The mean permitted delay of a turn is equal to the mean permitted delay of its approach and is
saved in the turn attribute tCur.
Visum evaluates, like in Step 3, the increased accuracy modified formula by Kimber and Hollis.

Step 5: Level of Service (LOS)


The concept of a LOS is not mentioned in the Kimber model. To create consistency within ICA
and because the RFC (Ratio Flow to Capacity) skim was criticized as being insufficient, Visum
still defines a LOS per approach as a classification of the mean delay (table 90).
LOS

Mean Delay [s / PCU]

0 - 10

>10 - 15

>15 - 25

>25 - 35

>35 - 50

>50

Table 90: LOS for calculation according to Kimber based on the mean delay

Visum calculates the LOS of the entire node accordingly, on the basis of the volume weighted
mean delay of all approaches.

5.5.4

Signal time optimization


Within the scope of the intersection capacity analysis using ICA, you can optimize the signal
times for individual signalized junctions in two ways:

PTV AG

Green time optimization (see "Green time optimization" on page 279)


Cycle and green time optimization (see "Signal cycle and green time optimization" on
page 281).

277

Chapter 5: User model PrT

Furthermore, with signal coordination you can optimize the time intervals between more than
one light signal control in the network (see "Signal coordination (Signal offset optimization)" on
page 281).
Note: Optimization regards only those nodes (main nodes), whose effective control type =
signalized. Optimization does not regard those nodes (main nodes) whose SC has been
turned off or to which no SC has been allocated.

5.5.4.1

Data model for SC cycle and green time optimization

The following attributes of network objects are relevant for the cycle and green time
optimization:
Network object type

Attribute

Description

Signal control and


subordinate objects

All attributes which


describe signal times

Signal times and stage distribution in the initial state

SC

Reference to signal
coordination groups

Signal coordination
group

Cycle time family

At cycle time optimization with procedure


parameters UseCycleTimeFamily=True, only one
member of the cycle time family of the coordination
group is selected as a new cycle time.

SC

ICA maximum cycle time


for optimization
ICA minimum cycle time
for optimization

At cycle time optimization with procedure parameter


UseCycleTimeFamily=False the new cycle time is
selected from the interval between these two
attributes.

SC

Optimization method

0 = no signal time optimization for the signal control


at this node
1 = only green time optimization
2 = cycle and green time optimization

SC

Turned off

If the SC has been turned off, no signal time


optimization will be calculated for the node (main
node).

Turn

The attribute for the


design hourly volume set
in the procedure
parameters

Turn volumes

Node model and


subordinate objects

All geometry attributes

Lane allocation at node

Optimization is controlled by the following procedure parameters (components of the


procedure parameters for intersection capacity analysis):

278

Procedure parameter Data type (Standard)

Description

Automatic green time Boole (False)


optimization

Are the signal times always optimized within the ICA


calculation? If yes, it depends on the SC attribute
Optimization method which optimization method is
applied to which SC.

PTV AG

Chapter 5.5: Impedances at node

Procedure parameter Data type (Standard)

Description

UseCycleTimeFamily Boole (True)

At cycle time optimization with procedure parameters


UseCycleTimeFamily=True, only one member of the
cycle time family of the coordination group (if available)
is selected as a new cycle time.

Precision of
computation

5.5.4.2

Seconds or tenths of a Via this parameter you can decide whether seconds or
second
tenths of a second are permitted as green time start and
end.

Green time optimization

The predefined cycle time applies as predefined for pure green time optimization.

Green time optimization for stage-based signal controls


The following steps are necessary for calculating the green time split:
1. Deconstruct approaches into lane groups (already calculated for capacity analysis).
2. Calculate adjusted volume and saturation flow rate for each lane group (already calculated
for capacity analysis).
3. For each stage in the signal timing plan, determine the critical lane group.
4. Allocate green time based on critical lane group volume/saturation flow rate ratios.
5. Check that the allocated green times meet all the constraints.
Green time split is calculated as follows:
Gi =

(v s )ci
Gte
(v s )ci
i

where
Gi

effective green time for stage i

(v/s)ci

ratio of volume v and saturation flow rate s for critical lane group ci in stage i

Gte

total effective green time for cycle

The total effective green time for a cycle is the same as the cycle time deducting all intergreens
between consecutive stages. The intergreen between two stages is zero, if the stages share
signal groups. Otherwise, intergreen is given by the attribute Default intergreen of the signal
control.
Each stage must also maintain the minimum green time, which is given by the Minimum green
time attribute of the signal control. If the calculated green time for a stage is less than the
minimum green time, then the green time split equation is rerun with the stage below its
minimum green time omitted. The omitted stage is assigned the minimum green time. That
minimum green is subtracted from the total effective green time and the green time split is
recalculated.
As a result of optimization, new values are assigned to the attributes Green time start and
Green time end of the stages.

PTV AG

279

Chapter 5: User model PrT

Green time optimization for signal group-based signal controls


The optimization of signal group based signal controls results from the following steps of the
procedure for stage-based signal controls:
1. Fictitious stages are generated from the current greentimes of the signal groups.
Visum first defines set T of all switching points from the attributes Green time start and
Green time end of all signal groups and sorts these in ascending order. For each interval
between consecutive times ti and ti+1 in T generate a stage which contains all signal groups
which have been released during [ti ; ti+1).
2. The fictitious stage-based signal control is optimized as above (see "Green time
optimization for stage-based signal controls" on page 279).
3. The signal group green times are read from the optimal stage distribution.
Green time for each signal group results from the green time of all stages which contain the
signal group. Because all of these are neighboring stages due to construction, there is only
one green time for the signal group.

Green time optimization for external signal controls and RBC


Visum can be used to optimize Vissig signal controls. Stages have to be defined for this signal
control. Optimization of non-stage based Vissig controls or controls of the RBC type will be
made available later.
To exclude selected stages from the optimization to keep their lengths as set in the original
signal timing plan, select 'true' for the attribute Pseudo stage of these stages.
Visum executes the following steps to calculate the green time split:
1. With the current signal timing plan, execute an ICA calculation and determine both
saturation flow rate and volume for each lane group.
2. Solve the linear optimization problem:

Max z

P, G( l ) P sl tP z ql l L
min

tP tP

tP C

P
P

where
L

set of all lane groups

cycle time

sl

saturation flow rate of lane group l

ql

volume of lane group l

tP

green time duration of stage P

min

tP

280

minimum greens of stage P

PTV AG

Chapter 5.5: Impedances at node

The first secondary condition expresses that the share z of the volume per lane group
depends on the green times of the stages provided for this group. The share z is
maximized.
3. With the optimized signal timing plan, execute another ICA calculation.
4. If the total mean wait time has not improved, cancel the calculation and continue with step
5. If the saturation flow rates have changed, continue with step 2. Otherwise, continue with
step 5.
5. To the stages' attributes Green time start and Green time end, allocate the values
obtained from the recent optimum solution.

5.5.4.3

Signal cycle and green time optimization

If you select the Signal cycle and split optimization for a node, Visum calculates an optimal
cycle time for the signal control at the node and at the same time an optimal green time split for
this cycle time. If several (main) nodes belong to a signal control, then automatically all (main)
nodes of this signal control will be optimized.
The calculation includes the following steps:
1. Determine the set T of permitted cycle times at the SC. If the procedure parameter Use
cycle times of coordination groups is active and if the SC belongs to a coordination
group, then only cycle times of the coordination group's cycle time family are permitted.
Otherwise, any cycle time (integer [in seconds]) from the interval between the SC attributes
ICA minimum cycle time for optimization and ICA maximum cycle time for
optimization is permitted
2. To each permissible cycle time t from T the following applies:
Specify optimal green times g*(t) for predefined cycle time t.
Use ICA to calculate the total wait time at the node for g*(t).
3. As an optimal cycle time t* select the t with minimum total wait time. In addition, set the
optimal green time split g*(t*).
The ICA calculation of the total wait time at the node only provides valid values, if the sum of
critical v/s ratios is smaller than or equal to 1. To greater sums always t* = max(T) applies. If
the sum of the minimum green time and intergreens for all stages or signal groups are larger
than the calculated t*, t* is set to the smallest t of T which is larger or equal to this sum. If no
such t exists, t* is set to the sum independently of T.

5.5.4.4

Signal coordination (Signal offset optimization)

Signal cycle and split optimization always refers to individual signal controls. Signal offset
optimization, however, is used to optimize the offset between the signal times of neighboring
nodes in such a way, that vehicles can pass several consecutive signal controls on green. The
general aim is to minimize the total wait time for all vehicles at the signal control.
Notes: The method does not regard the attributes of the node geometry. Especially the stop
line position per lane is not taken into consideration.
Signal coordination dos not include signalized nodes or main nodes to which no SC has been
allocated or whose SC has been turned off.

PTV AG

281

Chapter 5: User model PrT

Example
We will demonstrate the task with the example network displayed in illustration 68.

Illustration 68: Example network for signal coordination

In the network in illustration 68 the six inner nodes have signal controls and the outer nodes are
only there to connect the four zones. Link and turn volumes result from an assignment. Lane
allocation is usually selected, so that at each approach of a node, a shared lane exists for the
straight and right turns and a 100 m long pocket for left turns additionally. Additional lanes are
only located at individual approaches with an especially large traffic volume. All SC have the
same signal times (illustration 69).

282

PTV AG

Chapter 5.5: Impedances at node

Illustration 69: Green time split at all nodes with succeeding left turns

With a cycle time of 80 s, straight and right turns each have a green time of 30 s. Signal groups
for left turns have 5 s more and are protected within this time.
Signal times and lane allocation are selected in such a way that the resulting capacity is
sufficient for all turns. Wait times can occur if neighboring SCs are badly coordinated. For this
example we first assume an offset time of 0 s for all SC. The assignment result illustrated by
link bars results as overlapping of seven paths and one of these is highlighted in the
illustration 70.

PTV AG

283

Chapter 5: User model PrT

Illustration 70: A path through the example network passes SCs at nodes 7003, 8003, 8002 and 9002

This route passes the signalized nodes 7,003, 8,003, and 9,002. Vehicles exiting node 7,003
in direction 8,003 form a group that starts at the beginning of the green time, i.e. at second 0.
Travel time tCur, on the link between 7,003 and 8,003, is 38 s. Without accounting for dispersal
of the group, the first vehicles reach node 8,003 at second 38. The distribution of the actually
driven speed by vehicles leads to a resolution of the original compact platoon (illustration 71).

Illustration 71: Progression quality for approach West at node 8003

284

PTV AG

Chapter 5.5: Impedances at node

On the left, the diagram shows the arrival rate by cycle second. The first vehicles arrive at
second 30. The arrival rate then steeply increases and decreases as of second 52. The signal
group to continue the journey also has a green time between second 0 and 30. The major part
of the platoon therefore reaches the node at red. The second diagram shows the
corresponding development of the queue length and the third diagram the resulting wait time
in vehicle seconds dependant on the arrival second. The total wait time across all arrivals is
19,069 vehicle seconds, which corresponds to a mean value of 39.20 s per vehicle. This is an
example for bad coordination.
At node 8,002, the situation is much more favorable (illustration 72).

Illustration 72: Progression quality for approach North at node 8002

The vehicle group again starts driving at second 0. The travel time on link 8,003 - 8,002, with
tCur = 41 s, is similar to before. However, the continuing signal group 4 for left turns, at node
8, has a green time from second 40 to second 75. Most of the vehicle group arrives during
green time. The queues are distinctly shorter and the total wait time is only 1,608.80 vehicle
seconds (mean: 4.37 s per vehicle).
In this simple example, the aim of signal coordination would be to change the offset between
nodes 7,003 and 8,003, so that the entire vehicle group arrived at 8,003 during green time. At
the same time, however, you would want to maintain the favorable offset between 8,003 and
8,0002. Because a convenient coordination should be achieved not only for one but several
paths (in the example, seven) simultaneously, signal coordination usually minimizes the total
wait time of all SCs by changing the offset times.

Model
Signal coordination in Visum can be used for optimizing SCs in a network, not only along a
linear corridor, as it corresponds with the traditional optimization of the progressive signal
system. This section describes how the optimization model is set up, which Visum solves by
using a standard procedure for mixed integer linear optimization. All attributes which describe
input and output of the procedure are summarized in the following section (see "Input attributes
with effect at signal coordination" on page 288).
Good coordination requires the SCs either have the same cycle times or that the cycle times
are at least in a simple ratio (for example 2:1). Furthermore, SCs have to be located close to
each other, otherwise the platoon will have broken up so heavily by the time it has reached the
next SC, that the arrivals will virtually be uniformly distributed and the wait time cannot be
influenced through the choice of the offset. It is therefore generally not sensible to coordinate

PTV AG

285

Chapter 5: User model PrT

all SCs in one network. You determine which SCs should be coordinated, by defining signal
coordination groups and assigning them SCs (see User Manual, Chpt. 2.40.14, page 633). By
default, SCs are not assigned to any signal coordination group and are not coordinated.
For each signal coordination group define the set of the cycle times which are permitted for the
corresponding SCs. Please make sure that the cycle times actually make coordination
possible. Two SCs with cycle times of 60 s and 65 s can generally not be coordinated because
the platoon in each cycle takes place at a different cycle second. Suitable cycle times therefore
have a small LCM (least common multiple), for example, the family { 60 s, 80 s, 120 s } with
LCM = 240 s. Signal coordination optimizes offset times for each signal coordination group
separately and takes those SCs into consideration with cycle times belonging to the permitted
cycle times of the group. SCs with deviating cycle times are ignored and logged in the message
file.
Important for coordination is the behavior of the vehicle platoon during the journey from one SC
to another. Visum determines platoons by analyzing the assignment results for one or more
selected PrT demand segments. From the saved paths of the assignment, Visum determines
how many vehicles on their way first pass signal group SG1 of the SC SC1 and then signal
group SG2 of the SC SC2. We call such a combination of two consecutive signal groups with
one volume a coordination path leg or shorter path leg.
A path leg is relevant for the coordination, if the following properties apply.

Path leg starts and ends at SC of the same coordination group


Path leg contains no nodes of controller type All-way stop
Path leg passes through node of controller type two-way stop only in the direction of the
major flow
Path leg does not pass through other signalized nodes
Travel time on the path leg is short enough, so that a significant platoon remains
(specification below)
No link along the path leg exceeds a threshold for the saturation

All conditions except for the first one are aimed at a platoon remaining along the path leg.
Optimization treats the traffic flows on all path legs interdependently. In each case it is
assumed that within a cycle all vehicles start as a platoon at the beginning of the green time.
This means, that beginning with the green time start, outgoing vehicles flow off with the
saturation flow rate qmax, until the volume per cycle has been exhausted. The following applies:
PCU
q max = 1900 ------------ N
h

Here, N is the effective number of lanes for the turn. If the green time duration is insufficient and
does not allow the volume allocated to a cycle from the assignment to exit with qmax, Visum
ignores the excess volume and logs this in the message file.
The platoon resolution, solely caused by different vehicle speeds, describes the platoon
development formula according to Robertson. This model discretely divides the time in
increments (in Visum of 1 s) and displays the number at time t, at which a vehicle arrives at
the end of a path leg as a function of the number at time t < t, at the beginning of the path leg
departing vehicle.
q' t + T = F q t + ( 1 F ) q' t + T 1

286

PTV AG

Chapter 5.5: Impedances at node

where
qt

the number of vehicles arriving at the end of the path leg in time step t

qt

the number of vehicles departing at the beginning of the path leg in time step t

1
F = -------------------with specified constants and
1 + T

travel time tCur on the path leg

For calculating queue lengths it is presumed that separate lanes of sufficient length exist for
separate signal groups at an approach. Visum generally assumes "vertical" queues for signal
coordination and does therefore not consider spillback upstream over several links or have an
effect on the capacity of the turns of other signal groups.
For the evaluation of the progression quality, Visum calculates a number of skims which are
used throughout literature. In the subsequent formulas CT determines the cycle time, GT the
green time and qt the number of vehicles arriving at a node in time step t.

t CT qt avg
t CT qt
Platoon index = ------------------------------------------- with avg = -----------------------CT
q
t

t CT

This size measures the "distance" of a volume profile of an equal distribution. The value varies
from 0 (equal distribution) to 2 (for a distinct platoon). A high value means that coordination is
worthwhile at this node, because the arriving vehicles are focused on part of the cycle time, so
that there is a chance of moving the green time there, by changing the offset time.
t GT qt
Vehicles at green = 100 ------------------------- .
qt
t CT

This size directly measures how well coordination works. It calculates which part of the volume
passes the node without stopping at the SC.

q
t GT t GT
------------------------ -------Platoon ratio =

CT
q
t CT t
The size also measures how well coordination works, whereas high values imply good
coordination. Especially high values are achieved when a large share of arrivals enter at green,
although the green ratio itself is smaller.
The platoon ratio PR is the basis for the important ArrivalType parameter in waiting time
calculations according to HCM.
1
2

3
ArrivalType =
4
5

PTV AG

if
if
if
if
if
if

PV < 0.5
0.5 PV < 0.85
0.85 PV < 1.15
1.15 PV < 1.5
1.5 PV < 2.0
2.0 PV

287

Chapter 5: User model PrT

Queue length queuet at a signal group to cycle second t results from the difference of
cumulative inflows and exit flows. For this calculation, Visum also calculates the delays of
travel times with specified arrival time in the queues and hence, the mean and total wait time.

Input attributes with effect at signal coordination


Signal coordination accesses the network objects and the input attributes displayed in table 91.
Note: Node geometry attributes such as the stop line position, for example, are not regarded
for signal coordination.
Network object

Attributes

Note

PrT paths

Volume

From assignment

Links, turns, main turns

A freely selectable
attribute

Is interpreted as travel time and will be summed up


for travel time calculation per path leg

SC with all components

All

Signal timing, cycle time, mapping of signal groups


and lane turns, selection of a reference SC that
has offset = 0.

Signal coordination
groups

Cycle time family and


assigned SC

Grouping of the SCs to be coordinated collectively

Table 91: Input attributes with effect at signal coordination

Output attributes at signal coordination


The effect of the signal coordination lies mainly in assigning the attribute offset of the
coordinated SC with an optimal value.
Alongside that, all skims listed above can be calculated for measuring the progression quality.
Their definitions first of all refer to a single path leg. In order to easier display results in a
network model, Visum aggregates the values of all skims on links and saves the results as link
attributes. Visum allocates the attributes at all approach links to signalized nodes which have
a volume of > 0. All link attributes for signal coordination results are contained in the table 92.
.

Name

Value type Value range

Meaning

SC coord vehicles on green

Double

0.0 .. 100.0

Number of vehicles which arrive during


green time [%]

SC coord platoon index

Double

0.0 .. 2.0

Definition see above

SC coord platoon ratio

Double

0.0 ..

Definition see above

SC coord arrival type

Integer

1 .. 6

Definition see above

SC coord wait time

Time

0 s ..

Total wait time [Vehicle seconds]


Note: For links to overloaded signal groups,
this value is set to 100,000 h.

SC coord maximum queue


length

Double

0.0 ..

Max. number of queued vehicles over all


cycle seconds [Veh]
Note: For links to overloaded signal groups,
this value is set to 100,000.

Table 92: Output attributes of links for signal coordination results

288

PTV AG

Chapter 5.5: Impedances at node

Note: By the name component 'SC coord', the attribute SC coord arrival typeis indicated as
signal coordination output attribute. It is not identical to the ICA arrival type attribute, which
is used as entry for ICA calculation. If you want to calculate the ICA impedance with an arrival
type which corresponds with the given offset time intervals, first perform the Signal offset
analysis and then copy the SC coord arrival type values to the ICA arrival type attribute.

Procedure parameters
Alongside the network object attributes, the procedure parameters listed in table 93 control
signal coordination.
Name

Value range (Standard)

Meaning

Automatic Analysis

Boole (True)

After signal coordination, the output link attributes


are automatically updated.

Coordination group set

Set of coordination groups Coordination is only carried out optionally for


(all)
selected signal coordination groups.

Demand segments set

Set of assigned
PrT_DSeg (all assigned
PrT_DSeg)

Optionally, path legs are only determined from


the assignment paths of selected demand
segments.

MaxSaturation

Double > 0 (80%), in


percent

If this saturation is exceeded on a path leg link,


the path leg is ignored for coordination, because
no platoon is retained with too high saturation.

MinPlatoonIndex

Double > 0 (0.4)

If the platoon index is below this threshold at the


end of the path leg, the path leg is ignored for
coordination, because the platoon is not distinct
enough.

RobertsonAlpha

Double > 0 (0.35)

Parameter for the platoon progression formula


according to Robertson

RobertsonBeta

Double > 0 (0.8)

Parameter for the platoon progression formula


according to Robertson

TravelTimeLinkAttr

numeric link attribute


(AddValue1)

When calculating the path leg travel time, for


each traversed link, TravelTimeLinkFac
TravelTimeLinkAttr is summed up

TravelTimeLinkFac

Double > 0 (1.0)

TravelTimeTurnAttr

Numeric turn attribute


(AddVal1)

TravelTimeTurnFac

Double > 0 (1.0)

TravelTimeMainTurnAttr

Numeric main turn


attributes (AddVal1)

TravelTimeMainTurnFac

Double > 0 (1.0)

MaxCalculationTime

Time

When calculating the path leg run time, for each


traversed turn, TravelTimeTurnFac
TravelTimeTurnAttr is summed up
When calculating the path leg run time, for each
traversed turn, TravelTimeMainTurnFac
TravelTimeMainTurnAttr is summed up
Calculation time for the solution of the
optimization problem is restricted. The best
solution found up to the specified time limitation,
is assigned.

Table 93: Procedure parameters for signal coordination

PTV AG

289

Chapter 5: User model PrT

Problem solution
To determine an optimal set of offset times per SC, Visum sets up a mixed integer linear
optimization problem. The deciding variables in this problem are the differences of the offset
times of neighboring SCs, the objective function is an in sections linearized approximation of
the wait time in dependency thereof. Secondary conditions express that the differences
between the offset times of adjacent SCs along each circle in the network have to be added to
an integer multiple of the cycle time.
A detailed description of the method is found in Mhring, Nkel, Wnsch 2006.

5.6

PrT skims
With the Calculate PrT skim matrix procedure the PrT skims which are listed in table 94 can be
calculated (see User Manual, Chpt. 5.8, page 1061). The abbreviations in parentheses
indicate the file extensions which are used by default for skim matrix output in version files.
t0-PrTSys (TT0)

TSys-specific travel time t0 in unloaded network

tCur-PrTSys (TTC)

TSys-specific travel time tCur in loaded network

AddValue1..3 (AD1 - AD3)

Sum of AddValue

Trip distance (DIS)

Distance covered from origin to destination

Direct distance (DID)

Direct distance between origin and destination zone

Speed v0-PrTSys (VP0)

TSys-specific speed v0 in unloaded network

Speed vCur-PrTSys (VPC)

TSys-specific speed vCur in loaded network

Toll (TOL)

Toll of traversed links

Impedance-PrTSys (IMP)

TSys-specific impedance in unloaded network

AddValue-TSys (ADS)

Sum of TSys-AddValue data

User-defined (UDS)

Flexible calculation of a mean attribute value per OD pair, the linkage of


attributes of different traversed network objects is also possible (see
"Using user-defined PrT skims" on page 1063)

Table 94: PrT skims

Calculating skims is either done via the best path as regards to the set criterion or via
aggregation from the paths of an assignment result calculated beforehand. In this case you can
select one of the aggregation functions listed in table 95.
Minimum impedance

Skim value calculated from the path with minimum impedance

Maximum impedance

Skim value calculated from the path with maximum impedance

Mean over paths

Skim value calculated as a mean over all paths

Mean over path volume

Skim value calculated as a mean over all paths weighted with the
corresponding path volume

Table 95: Aggregation functions for the skim data calculation

290

PTV AG

Chapter 5.7: Distribution of the traffic demand to PrT connectors

Moreover, the set of origin-destination relations for skims can be calculated, and also restricted
like the type of network objects which are included in the skim calculation.

5.7

Distribution of the traffic demand to PrT connectors


The distribution of PrT origin and destination demand onto PrT connectors can be done freely
or proportionally. In the case of proportional distribution, again two options are differentiated:
distribution of the total demand or distribution per OD pair (see "Distribution of demand of a
zone to the connectors" on page 47).

Free distribution
During route search, only the connector time is considered and traffic demand is distributed
without further constraints onto the routes with the lowest impedance.

Proportional distribution of total traffic


Before the route search is carried out, the share of total origin and destination traffic is
calculated for every zone whose demand is to be distributed proportionally. From this, a virtual
connector capacity (= proportion origin/destination demand) can be deduced for every
connector which modifies the impedance of the connectors during assignment in such a way
that proportional distribution is achieved. The correspondence between the distribution of the
assignment and the predefined values depends on the selected assignment procedure and the
selected VD function for connectors. A steep VD function should be used. In addition to this,
the connector times must not be too low so that the connector impedance has an effect on the
route search. When using this option, it should be noted, that the distribution may have very
different effects on the individual OD pairs. If the link impedance equals the displayed lengths,
practically all trips from zone 1 to zone 3 lead via node 2. The vast majority of trips from zone
1 to zone 2 however are made via node 1.

60 %

Zone3

Zone1

Zone2

40 %

1
Illustration 73: Example network for proportional distribution of the traffic demand

Example: Connector capacity determination for proportional distribution of the total traffic
(illustration 73)

Zone 1 has proportional distribution


Zone 2 has proportional or absolute distribution

PTV AG

291

Chapter 5: User model PrT

Zone 3 has proportional or absolute distribution


Travel demand from zone 1 to zone 2: 1,000 trips
Travel demand from zone 1 to zone 3: 400 trips
Origin demand zone 1: 1,400 trips
Connector zone 1 node 1: 40 % proportion
Connector zone 1 node 2: 60 % proportion
Capacity of connector zone 1 node 1 is 40 % x 1,400 = 560 trips
Capacity of connector zone 1 node 2 is 60 % x 1,400 = 840 trips
Steep VD function for connectors, for example BPR function with a = 1, b 4, c 1

Proportional distribution of each individual relation (MPA)


Alternatively, the proportional distribution can be applied to each OD pair. This leads to the
following distribution in the example above:

Example: determination of connector capacity for proportional distribution per OD pair:

Zone 1 node 1 zone 2 with 40 % 1,000 = 400 trips


Zone 1 node 1 zone 3: 40 % 400 = 160 trips
Zone 1 node 2 zone 2 with 60 % 1,000 = 600 trips
Zone 1 node 2 zone 3: 60 % 400 = 240 trips

5.8

Blocking back model


The blocking back model (pseudo-dynamic assignment, pa) fills the gap between merely static
procedures, which do not have any temporal reference and cannot determine congestionrelated wait times, and dynamic procedures that require long computation times. The
procedure is much faster than any dynamic assignment, requires less memory capacity and
can furthermore deliver information on congestion phenomena. The procedure can be applied
in conjunction with static assignment in order to estimate queue lengths and wait times in
oversaturated networks. In contrast to dynamic-stochastic assignment, it is suitable for
networks with > 50,000 links and only requires few additional data for temporal distribution of
the demand.
The general idea is to re-assign route volumes that were calculated with any static assignment
at an earlier stage. Output data of the procedure:

new volumes on links, connectors, (main) turns and (main) nodes


queue lengths on links and connectors
wait times on links

The original volumes of links, connectors and (main) turns resulting from the assignment are
stored with the following attributes:

Volume demand PrT with base


Volume demand DSeg
Volume demand PrT

Original node volumes can be found in the following attribute:

292

PTV AG

Chapter 5.8: Blocking back model

Volume demand PrT

The blocking back model is divided into two phases, the second phase is optional.

Phase 1 (congestion calculation)


Along a route, the demand share is passed on from one link to the next until a restricting
capacity has been reached. The following rules apply in this process.
1. The volume passing from one link to the next cannot exceed the capacity (PrT) of the link,
the capacity of the To node, and the capacity of the turn. For links, the amount of traffic
leaving the link counts (bottleneck at end of link).
2. The queue on a link can never exceed the stocking capacity of the link.
3. As soon as a queue forms on a link in some direction, no traffic can pass the link even if the
respective route does not lead across the bottleneck that is causing the congestion.
The fourth rule which limits the inflow of a link, directly results from this.
4. The inflow of traffic on a link is limited to the amount resulting from capacity plus stocking
capacity.

Phase 2 (precise wait time calculation)


Already in phase 1, wait times are calculated from the resulting queue lengths and the duration
of this phase. In the optional phase 2, more precise wait times are calculated by simulating also
the discharge of the congestion. New traffic is not imported, but rather the traffic stored in the
local queue lengths is distributed along the routes according to the same rules as in the first
phase. This is done in small time steps, where the capacities still limit the inflow. After each
step, the level of congestion is stored The second stage ends, when all local congestion is zero
and thus no traffic remains in the network. This results in a series of snap shots of the level of
congestion at different times which are then used to calculate a delay.

5.8.1

General notes on the blocking back model


The blocking back model is no independent assignment procedure, but it modifies the results
of previously run assignments or of the running assignment. As an option, the blocking back
model can be carried out together with an assignment (see User Manual, Chpt. 5.5,
page 1006).
The blocking back model only applies to PrT transport systems. Assuming that PuT transport
systems are either not affected by any congestion or that the timetables used already regard
the wait times. PuT-caused congestion on commonly used links can be neglected or can be
considered by a basic volume.
Since volumes of different PrT demand segments are summed up before entering the queue
length, all volumes are invariably converted into car units.
The following two operating modes are possible:

PTV AG

You can calculate the blocking back model post-processed following an assignment. It
therefore does not influence the route choice.

293

Chapter 5: User model PrT

Alternatively, you can execute the blocking back model in the external iteration of an
assignment procedure. The results are then included in the link impedance and therefore
in the route choice. This modus operandi is not recommended, since it significantly
downgrades the convergence of the particular assignment procedure. To take the blocking
back impact on the route choice into consideration during the assignment, you should
rather use the procedure Assignment with ICA (see "Assignment with ICA" on page 354).

In either case it can be combined with the following assignment procedures: Incremental,
Equilibrium, Equilibrium_Lohse, TRIBUT and any stochastic procedure. However, it cannot be
combined with a dynamic assignment procedure.
If an assignment has already been calculated for at least one demand segment, which is not to
be recalculated, the blocking back model is calculated prior to the execution of the assignment
of the already assigned demand segments. This is to ensure that the values for tcur and tw are
consistent with the current network status and to avoid that assignments with a blocking back
model share and those without are combined.
If the blocking back model is calculated as an integrative part of other procedures, one has to
differentiate between iterative procedures (Incremental assignment, Equilibrium_Lohse and
Stochastic assignment) one the one hand and balancing procedures (Equilibrium assignment
and TRIBUT) on the other hand. During those procedures running step-by-step a corrected
volume will always be calculated after the volume determination and also the wait times will be
calculated by the blocking back model. Then, in the i-th iteration, from the corrected volume a
new value tiCur will be calculated for the current travel time and the wait time tiw will be added.
i

t = t Cur + t w

As new value, the arithmetic mean Ti of all former ti is used, which is also considered in the
subsequent route search.
i

k = 0 t

k = 0 tCur + tw
k

T = --------------------- = --------------------------------------i+1
i+1

Here, t0Cur = t0 and t0w = 0 applies.


The consideration of earlier values guarantees the necessary attenuation and enforces the
procedures convergence. If only the current value would be taken into account when
calculating the impedances in the next iteration, the total traffic volume would shift back and
forth between alternative routes without converging towards a result.
The value returned for the wait time tw at links however, is just the wait time value determined
during the previous calculation of the blocking back model. In the case of convergence, it is
consistent with the times used in the assignment. The following applies:

For the calculation of the travel time tCurNew, using the corrected volume is necessary, since
the increase of the travel time above the capacity limit is no longer determined by volumedelay functions but modeled by explicitly calculated wait times.
If there is neither any congestion nor a decrease in the volume due to a flow-rate loss, tCur
= tCurNew and tw = 0 apply in any case. The impedance is unchanged compared to a
conventional assignment in this case.

294

PTV AG

Chapter 5.8: Blocking back model

If the blocking back model is integrated into an equilibrium assignment (not recommended), the
selected procedure is calculated first and the blocking back model is calculated subsequently
in an outer loop. Both methods are based on the fact that the volume of a link equals the total
volume of all routes traversing that link. For that reason a link-related modification of the
volume, as performed by the blocking back model would have no effect.
Instead, the result of the calculation of the blocking back model is used to modify the VD
functions of each link temporarily so that identical travel times result for unchanged network
volumes and for the changed network volumes with the original VD functions. These modified
VD functions can then be used for another iteration of an equilibrium assignment. If the network
volume has not changed, an equilibrium state has been reached which regards the modified
travel times tCur that result from the blocking back model. Otherwise a further iteration is carried
out, that includes blocking back model and assignment. As is the case with other methods, the
modified VD functions are averaged over several iteration steps in order to suppress the
alternation of the route choice between several alternatives.
The equilibrium state that is reached by this integrated calculation procedure is characterized
as follows: in due consideration of the changes to the travel times (and thus to the impedances)
which result from the volume calculated by means of the blocking back model, the travel time
(the impedance) is the same for each route of an OD pair.

Limiting capacity
According to rule 1, the traffic flow from link to link along a route is limited by the capacity of the
link and the capacity of the link's ToNode and the capacity of the turn during the blocking back
model calculation. In the blocking back model parameters you can select individually, whether
link and turn and node capacities are to be regarded. The settings have the following meaning:

Link capacity restricts the outflow per link. As threshold, either the link attribute Capacity
PrT can be used or the summed up Capacity PrT of the outgoing turns. The latter option
is only provided for compliance with out-dated versions. It is no longer recommended. It is
recommended to use the option Turn capacity instead.
Node capacity restricts the flow per node (sum of all turn volumes) to the node attribute
Capacity PrT. These node capacities are only regarded for traffic flows on secondary links
(tmodelspecial = true) towards the node. Traffic flows on major legs therefore also have an
effect on crossing routes via secondary links.
Turn capacity restricts the flow per turn to the turn attribute Capacity PrT.

These three options can be combined at will.


Furthermore you can decide by node, whether the global blocking back model parameter
settings are to be regarded; alternatively, a node-specific setting (node attribute Use preset
blocking back capacity settings = activated) can be used instead. The node-specific setting
is regarded for all turns via this node and for all links leading into this node. To regard the turn
capacity only at particular nodes, for example, then exclude the consideration of turn capacities
in the global blocking back model parameters and activate the attributes Use preset blocking
back capacity settings and Use turn capacity in blocking back at the particular nodes.

5.8.2

Procedure of the blocking back model


The procedure is divided into the following steps:

PTV AG

Determining the excess congestion factor

295

Chapter 5: User model PrT

Formation of congestion (phase 1)


Relief of congestion (phase 2) optional
Determining the wait times

Determining the excess congestion factor


Prior to the actual simulation of the queuing up, the excess congestion factor is calculated for
the network. In this process, the volumes and capacities of the links, nodes and turns for which
you have preset that they are to be regarded are taken into account.
For a single link L, the excess congestion factor Link(L) is given by
VolDem ( S )
Link ( L ) = ----------------------------------------------------------------------------------------------------------Cap ( L ) ScalingFactor q Basic volume ( L )

Here, VolDem(L) is the link volume resulting from assignment, Cap(L) is the PrT capacity of the
link, and ScalingFactor is the scaling factor for capacities from the blocking back model
parameters. Furthermore, VolBasic volume(L) is a basic link volume. You can select it in the
general procedure settings via PrT settings > Assignment.
Analogously, excess congestion factors Turn(T) and Node(N) are defined for turns T and nodes
N. Since basic volumes can only be preset for turns and links in Visum, the sum of the basic
volumes of the turns at the node is used as basic volume for nodes. Now, the excess
congestion factor of the network is the maximum of the excess congestion factors of all links,
nodes, and turns whose capacities are to be taken into account. It indicates by which factor the
(remaining) capacity in the network is exceeded at most.
The percentage of traffic corresponding to the reciprocal of this number can pass through the
network without any congestion. If 1, the procedure is not carried out. In this case, the
corrected volumes (Vol) equal the volumes calculated in the assignment (VolDem), thus no
congestion occurs.
If the denominator in the formula for the excess congestion factor calculation falls below 0 or
becomes 0 for a link or node or turn, there is no more free capacity available and the procedure
terminates.

Simulation phase 1 Formation of congestion


In phase 1, queue lengths on links and connectors are calculated and also the reduced
(compared to the original values) volumes of links, connectors and nodes. Thereto, we let
traffic flow into the network step by step along the routes resulting from assignment, and in
contrast to the previous assignment, the rules 1 to 3 are observed here. However, rule 3 is
weakened by the permeability factor P which determines the share that can pass existing
congestions. If P = 0, rule 3 is satisfied.
Let N be the number of shares for the volume distribution in phase 1. You can specify this
parameter in the procedure parameters for the blocking back model. In order to enforce rules
1 to 3, we iteratively propagate the N-th part of the route volume from the origin to the
destination until we reach a link on which a queue or another bottleneck (link, node, or turn) has
already formed for which the capacity is exceeded. This is carried out N times until all of the
traffic has flown into the network. In this case, that part of the volume is not added to the link
volume, but to the queue length.
Find below a detailed description of the procedure in phase 1. These are the most important
abbreviations used in this section:

296

PTV AG

Chapter 5.8: Blocking back model

VolDem

Volume demand: volumes from the assignment without consideration of withheld vehicles in
the blocking back model (i.e. if no blocking back model is calculated or no congestion occurs,
VolDem equals the volume Vol)

Vol
Cap
K
Q
P

(reduced) volume calculated in phase 1

Excess congestion factor

PrT capacity of a link, a turn or a node


Stocking capacity of a link
Queue length of a link (or connector)
Permeability of a link, describes the share of the flow that can pass existing queues

Firstly, the network is loaded with that portion of demand which does not cause congestions
yet. Then, the remaining demand flows into the network step-by-step. At first, the greatest
natural number n is determined, that satisfies n/N 1/. The general is then as follows:
Initialize Vol for all links, turns, nodes and connectors by entering 0.
Initialize Q or all links and connectors by entering 0.
For all links L and connectors C, load Vol(L)*n/N or Vol(C)*n/N, respectively.
For j = n+1 to N
For each demand segment
For each route R of the demand segment
Load VolDem(R) / N to route R.

Loading a volume flow to a route R with the n-th part of VolDem (flow) is performed as follows.
Let L0, L1, ..., Lk be the generalized links of a route, i.e. L0 is the origin connector, Lk is the
destination connector, and the real links are in between. Now, the traffic from the origin zone
flows via L0, L1, ..., Lk to the destination zone, at which the traffic flow is always limited by the
capacities of the links and turns and nodes and by congestions that might have formed.
Capacities bear limiting effects as described below. Let toNode(L) be the To node of a link L and
let Turn(Lj, Lj+1,T) be the turn from L to Lj+1 for the links L and T. Now, the flow from Lj to Lj+1
is limited by the capacity of Lj, and by the capacity of the To node of Lj, and by the capacity of
the turn from Lj to Lj+1.
Note: If you have decided that a particular capacity should not have an effect, then the
calculation assumes an infinite capacity. Connectors have an infinite capacity by definition.
The maximum volume maxFlow from Lj to Lj+1 then is
maxFlow(Lj, Lj+1) = min{Cap(Lj) ScalingFactor - VolBasic volume(Lj),
Cap(toNode(Lj)) ScalingFactor - VolBasic volume(toNode(Lj)),
Cap(Turn(Lj, Lj+1)) ScalingFactor - VolBasic volume(Turn(Lj, Lj+1))}

If the amount of in-flowing traffic on a link of the route exceeds the amount, that can flow off to
the next link, then the portion of traffic that keeps flowing depends on the remaining free
capacity:

PTV AG

297

Chapter 5: User model PrT

Function Load(R, flow):


For j = 0 to k-1
propagatingFlow = flow
If Q(Lj) > 0
propagatingFlow:= propagatingFlow * Permeability(Lj)
propagatingFlow:= min(propagatingFlow, maxFlow(Lj, Lj+1))
Vol(Lj) := Vol(Lj) + propagatingFlow
Vol(toNode(Lj)) := Vol(toNode(Lj)) + propagatingFlow
Vol(Turn(Lj, Lj+1)) := Vol(Turn(Lj, Lj+1)) + propagatingFlow
Q(Lj) := Q(Lj) + (flow - propagatingFlow)
Propagate queue backwards

Traffic that cannot flow into the next link is added to the queue length. If the queue on a link
exceeds the maximum stocking capacity K, then backups will arise on previous links of the
route. In that process, the backup has to be subtracted from the volume(s) of the previous
link(s) again (also nodes and turns are concerned), since this flow actually cannot have
reached the congested link being located ahead in the route course:
Function PropagateQueue(R):
propagatingQ = 0
For j = k-1 to 1
If Q(Lj) > K(Lj)
propagatingQ := Q(Lj) - K(Lj)
Q(Lj) = K(Lj)
Q(Lj-1) := Q(Lj-1) + propagatingQ
Vol(Lj-1) = Vol(Lj-1) - propagatingQ
Vol(toNode(Lj-1)) := Vol(toNode(Lj-1)) - propagatingQ
Vol(Turn(Lj-1, Lj)) := Vol(Turn(Lj-1, Lj)) - propagatingQ

After phase 1, nodes require a special treatment for the following reason: Though there are no
turns at connectors, connector nodes are loaded in the process. To achieve the state, that the
node volume = sum of all turn volumes at connector nodes after phase 1, the node volume of
connector nodes is recalculated from the turn volumes after the procedure.
We use a simple example with two routes to illustrate the procedure. Route 1 leads from A to
D, route 2 from B to C. Both routes have a volume VolDem of 200 vehicles. The volume is
distributed to the routes in four iteration steps with 50 vehicles each. The number of iteration
steps is based on the procedure parameter Number of shares for flow distribution in phase
1. For reasons of simplification, only the link capacity is considered as limiting capacity in the
example. Route 1 is always charged first. There is a bottleneck on route 1. On route 2, a
backup arises though this route does not traverse the bottleneck link.

298

PTV AG

Chapter 5.8: Blocking back model

Illustration 74: Blocking back model, phase 1: Formation of congestion Iteration steps 1 and 2.

In the first two iteration steps, each of the two routes is loaded with 50 vehicles. Queues do not
form yet (illustration 74).

Illustration 75: Blocking back model, phase 1: Formation of congestion Iteration step 3, route 1

Route 1: On the highlighted link, a bottleneck is located in iteration step 3. Due to the
insufficient stocking capacity of this link, the queue propagates to the preceding link
(illustration 75).

PTV AG

299

Chapter 5: User model PrT

Illustration 76: Blocking back model, phase 1: Formation of congestion Iteration step 3, route 2

Since there is now a congestion on the link in the middle, also the vehicles following route 2 get
stuck in the queue (illustration 76).

Illustration 77: Blocking back model, phase 1: Formation of congestion Iteration step 4, route 1

Another 50 vehicles are added to route 1 in iteration step 4. As the stocking capacity of the link
in the middle is fully exhausted, vehicles continue to propagate backwards (illustration 77).

300

PTV AG

Chapter 5.8: Blocking back model

Illustration 78: Blocking back model, phase 1: Formation of congestion Iteration step 4, route 2

The 50 vehicles with route 2 cannot even reach the link in the middle; they all get stuck in the
congestion on the first link (illustration 78).

Simulation phase 2: Relief of congestion


During the simulation phase 1, the local queue length of each link and corrected volumes have
been determined. If phase 2 is not calculated (optional), the wait times for phase 1 are
calculated directly. If the relief of congestion is simulated, too, further wait times arise which are
determined on the basis of the continued simulation without further inflow of traffic until all
queue length reach zero. Any traffic passing through the network in phase 2 thus originates
from the queues determined in phase 1. The maximum transfer flow in each iteration equals
the Mth share of the capacity. M describes the procedure parameter Number of shares for
flow distribution in phase 2 and determines the number of iterations in this phase.
Accordingly, the M-th portion of the interval length of the first simulation phase elapses per
step. After each iteration, the queue lengths on all links are recorded.
We analyze the relief of congestion in the example first and then describe the procedure in
detail.

PTV AG

301

Chapter 5: User model PrT

Illustration 79: Blocking back model, phase 2, relief of congestion. Initial situation

The illustration 79 shows the initial situation prior to relief of congestion in phase 2. Only the
queue lengths from phase 1 are regarded, there is no further influx. For congestion relief, four
portions are used (M = 4).

Illustration 80: Blocking back model, phase 2, relief of congestion. Iterations step 1, route 1

On route 1, the maximum congestion efflux is limited by the link capacity Cap = 100. Thus, Cap
/ M = 25 vehicles can flow off in iteration step 1 (illustration 80).

302

PTV AG

Chapter 5.8: Blocking back model

Illustration 81: Blocking back model, phase 2, relief of congestion. Iteration step 1, route 2

On route 2, the maximum congestion efflux is limited by the capacity of the link in the middle.
Since two routes traverse the link in the middle, only a certain portion of the capacity is
available for route 2 for this iteration, (Cap / M = 100); this portion is (Cap / M) (VolDem(Route
2) / VolDem(link in the middle)) = 100 (200 / 400) = 50 (illustration 81).

Illustration 82: Blocking back model, phase 2, relief of congestion. Iteration step 2, route 1

During iteration step 2, again 25 vehicles flow off via route 1 (illustration 82).

PTV AG

303

Chapter 5: User model PrT

Illustration 83: Blocking back model, phase 2, relief of congestion. Iteration step 2, route 2

Again, 50 vehicles flow off via route 2 (illustration 83).

Illustration 84: Blocking back model, phase 2, relief of congestion. Iteration step 3, route 1

During iteration step 3 only some (12.5) vehicles flow off via route 1 which are part of the
remaining queue on the link in the middle (like in iteration 1 for route 2). The link on the right,
however, is traversed by only one route; that is why the total capacity is provided for the flow
off of the congestion for this iteration (Cap / M = 25) (illustration 84).

304

PTV AG

Chapter 5.8: Blocking back model

Illustration 85: Blocking back model, phase 2, relief of congestion. Iteration step 3, route 2

On the link in the middle, the remaining congestion can flow off via route 2 (illustration 85).
The congestion efflux in phase 2 thus works in a similar way as the formation of the congestion
in phase 1, save that the traffic does not enter the network via the connectors, as usual, but
exists at the links with congestion in the network. In each iteration, we let flow off a portion of
the traffic which is restricted by the capacities of the links and nodes and turns; thus, new
queue lengths will be obtained. This is repeated until either the maximum number of iterations
set for phase 2 is reached (user-defined parameter for the blocking back model) or until the
congestion is no longer available. More accurately, the procedure is described as follows.
Initialize prevQ with queue lengths on links and connectors after phase 1
For j = 1 until (max. number of iterations in Phase 2) or until any prevQ = 0
For each demand segment
For each route R of the demand segment
Calculate the congestion flow off for R according to M and the
capacities
and thus obtain currQ
Calculate wait time
prevQ:= currQ

In detail, the relief of congestion goes like this: In each iteration step, the M-th portion of the
capacity of links, nodes and turns is available. Thus, the maximum traffic that can flow off of
link L due to the link's capacity, is Cap(L) / M per iteration. To each route R, that traverses link
L, a certain share in the capacity is provided; this share equals the route's share in the original
total link volume, i.e. VolDem(R) / VolDem(L). For a link L that belongs to a route R, the
maximum outflow of a congestion results from the following formula:
maxOutflow(L) = (Cap(L) / M) (VolDem(R) / VolDem(L))

Furthermore, the outflow is restricted by the capacity of the To-Node and by the turn capacity.
Let L0, L1, ..., Lk again be the generalized terms for links of a route, i.e. L0 is the origin
connector, Lk is the destination connector, and the real links are in between. Thus, the
maximum outflow from Lj to Lj+1 results as follows:

PTV AG

305

Chapter 5: User model PrT

maxOutflow(Lj, Lj+1) = min{(Cap(Lj) / M) (VolDem(R) / VolDem(Lj)),


(Cap(toNode(Lj)) / M) (VolDem(R) / VolDem(toNode(Lj))),
(Cap(Turn(Lj, Lj+1)) / M) (VolDem(R) / VolDem(Turn(Lj, Lj+1)))}

The traffic flow that actually flows out comes from the existing queues. For each route R, the
traffic originating from the queue on link Lj is as follows:
sourceVolQ(Lj) = prevQ(Lj) (VolDem(R) / VolDem(Lj))

The origin traffic of a link (limited by the maximum outflow maxOutflow) flows to the next link.
This traffic is then added to the origin traffic on the next link. If maxOutflow is smaller than the
origin traffic, queues will form again. The following therefore applies:
Function QueueOutflow(R, M):
arrivedFlow = 0
For j = 0 to k-1
totalSourceVol := sourceVolQ(Sj) + arrivedFlow
propagatingFlow:= min(totalSourceVol, maxOutflow(Lj, Lj+1))
currQ(Lj) := currQ(Lj) - propagatingFlow
arrivedFlow := propagatingFlow
Propagate queue backwards

As in phase 1, the queue is propagated backwards:


Function PropagateQueue2(R):
propagatingQ = 0
For j = k-1 to 1
If currQ(Lj) > K(Lj)
propagatingQ := currQ(Lj) - K(Lj)
currQ(Lj) = K(Lj)
currQ(Lj-1) := currQ(Lj-1) + propagatingQ

Please note that the results of the blocking back model may depend on the order of routes that
are processed. However, the more shares you choose for the distribution of the traffic flow, the
smaller the possible differences will be. If the blocking back model is applied to the same
network for example, on the one hand with an equilibrium assignment and with LUCE on the
other hand, then the results might differ slightly even if all routes are identical.
This is due to the fact, that - in contrast to other assignment procedures - LUCE does not
directly provide routes, but bushes in the first instance, which represent multiple routes at the
same time. In conjunction with LUCE, the blocking back model calculations are performed
directly on the bush level. Since the bushes can include various from-links and to-links for each
link, the traffic flows need to be distributed appropriately. This is performed in a way as if
several routes were processed simultaneously. From this, slightly deviating results may be the
outcome.

Determining the wait times


Resulting from the second simulation stage are the values for the local queue length of each
link after each measuring section (iteration). These values together with the queue length after
the first simulation stage are used to form an integral of the total wait time over the measured
queue length.
The illustration 86 shows an example for the display of the integral indicating the overall wait
time over the interpolated measured queue lengths.

306

PTV AG

Chapter 5.9: Convergence criteria of the assignment quality

Illustration 86: Integral indicating the overall wait time over the interpolated measured queue lengths

This is expressed by the following formula:


Q
QL ( i ) + QL ( i 1 )
W L = I ------L- + ---------------------------------------------------
2M
2

with I being the duration of the first simulation interval in seconds. The sum extends over the
measured values with QL(0) indicating the queue length QL after the first simulation phase. If
the second phase is not calculated, the second term in the bracket is omitted and the wait time
results in the duration of the simulation interval for phase 1 and the queue length at the end of
the first phase.

This results in a mean wait time per vehicle unit as follows

0
if Q ( L ) = 0

=
WL
else
--------------------------------------------- effectivecapacity

On inks with traffic jams, the effective capacity results from the minimum of link capacity
attribute Cap and reduced volume Vol, created through spillback congestion.

5.9

Convergence criteria of the assignment quality


To assess the convergence speed Visum traces the convergence criteria for each iteration, for
all static assignment procedures (apart from incremental assignment). Stochastic assignment
only stores the internal iterations of the previous external iteration (see "Stochastic
assignment" on page 365).
These criteria are output in a list as indicators of the goodness of a PrT assignment (see User
Manual, Chpt. 5.7.1, page 1060). They are initialized prior to each assignment and stored with
the version file.

PTV AG

307

Chapter 5: User model PrT

Among others, the following criteria are calculated:

Hypothetic vehicle impedance

Minimum impedance value calculated hypothetically for the next iteration step on the
assumption that all vehicles based on the current impedances in the network use the
best path.

Gap = (Veh.Imp.- hypothet. Veh. Imp.) / hypothet. Veh. Imp.

Degree of convergence for the network.


The value is the weighted volume difference between the vehicle impedance of the network
of the current iteration and the hypothetical vehicle impedance.

Total Excess Cost TEC (Total Excess Cost)

TEC =

ij r P

min

[ Rr R ij ] q r
ij

where

TEC

Difference between total impedance in the charged network and the hypothetical
impedance resulting if all vehicles took the shortest path per OD pair.

Pij

Number of routes from i to j

Rijmin

minimum impedance among all routes from i to j

Average Excess Cost AEC (Average Excess Cost)

AEC = Excess cost per vehicle


TECAEC = ---------n

The following applies:


n = Number of trips: Total demand in the demand matrix minus the diagonal, thus the sum
of demand contributing to the assignment, no internal traffic.

5.10

Distribution models in the assignment


In Visum, some of the assignment procedures work like this: first, a number of alternatives
(routes or connections) are determined, and then the total demand per OD pair is distributed to
the alternatives. These are the (static) stochastic PrT assignment, the dynamic-stochastic PrT
assignment and the timetable-based PuT assignment. PrT assignment procedures use
alternative routes from origin zone to destination zone, whereas the PuT assignment
procedure provides alternative connections (routes with detailed departure times). For
simplification, we will only mention routes below in this section.
A distribution model determines the share of demand which is assigned to a certain route. This
portion depends on the impedance of a route. In any case, the percentage Pia of route i in
terms of the demand by OD pair in the time interval a is determined by including the impedance
Ria in a distribution function and then calculating the utility Uia of the route. For this distribution
function the Kirchhoff, Logit, Box-Cox, Lohse models and Lohse with variable Beta are
available. The following approach applies to all models:

308

PTV AG

Chapter 5.10: Distribution models in the assignment

1. Impedance Ria is converted to the utility Uia of route i in the time interval a:
Uia = f(Ria)

2. From this utility Uia the percentage of demand Pia is calculated (where n is the total number
of routes).
a

a
P i :=

Ui
----------------------n

j = 1 Uj

The models reveal differences in the functional relation f of impedance and utility.

5.10.1

The Kirchhoff model in the assignment


The utility is as follows:
a

Ui = Ri

The percentage of demand is calculated as follows:


a

a
P i :=

Ri
-----------------
a
Rj
j

The sum of all routes j is taken and is used as a parameter for modeling the impedance
sensitivity. In this distribution method, the ratios of the various impedances are decisive. It
does not matter, therefore, whether two routes have impedances of 5 and 10 minutes, for
example, or 50 and 100 minutes the distribution is the same. The illustration 87 shows the
parameterization of the Kirchhoff distribution model on the interface.

Illustration 87: Parameterization of the Kirchhoff distribution model

5.10.2

The Logit model in the assignment


In this model, the difference, rather than the ratio, between the impedances is used to
calculate distribution. The impedance is additionally divided by a scaling divisor.
The utility is as follows:
a

Ui = e

PTV AG

Ri

309

Chapter 5: User model PrT

The percentage of demand is as follows:


a

a
P i :=

Ri

e
------------------------a

j e

Rj

Parameter describes the sensitivity of passengers towards increased impedances. As in this


case the differences rather than the ratios of the impedances are considered, it does not matter
whether two routes have impedances of 5 and 10 minutes, for example, or 95 and 100 minutes.
The illustration 88 shows the parameterization of the Logit distribution model on the interface.

Illustration 88: Parameterization of the Logit distribution model

5.10.3

The Box-Cox model in the assignment


This distribution model is based on the Box-Cox transformation. For the given 0, the BoxCox transformation is explained as follows.

()

x 1
-------------(x)

log ( x )

if 0
if = 0

When calculating the utility, b()(Ria) is now included in the Logit model instead of Ria, thus
a

Ui = e

()

( Ri )

results.

The percentage Pia of the route i in terms of the demand for time interval a is then calculated
as follows:
a
P i :=

()

( Ri )

e
-------------------------------------a
()

j e

( Rj )

The importance of the Box-Cox model is illustrated by the two special cases below.

310

= 0 (leads to the Kirchhoff distribution)

PTV AG

Chapter 5.10: Distribution models in the assignment

With these parameter settings, b(0)(Ria) = log(Ria) applies, thus the following applies to the
choice:
a

a
Pi

log ( R )

i
Ri
e
- = -----------------= ---------------------------------a

log ( R j )
a
Rj
e

This is precisely the Kirchhoff model.

= 1 (leads to the Logit distribution)


With these parameter settings, b(1)(Ria) = (Ria-1) applies, thus the following applies to the
choice:
a

a
Pi

( Ri 1 )

i
e
e
- = -----------------------= -----------------------------------a
a
( Rj 1 )
Rj
e
e

This is identical to the Logit distribution.


The illustration 89 shows the parameterization of the Box-Cox distribution model on the
interface.

Illustration 89: Parameterization of the Box-Cox distribution model

5.10.4

The Lohse model in the assignment


In this model, the impedances are related to each other in an entirely different way.
R ai

--------- 1
R amin

e
a
P i := ---------------------------------------------applies.
2
a

j e

Rj

--------- 1
R amin

Here, Rmina := minjRja is the smallest occurring impedance, and is again a parameter to
control the impedance sensitivity. When calibrating, do not forget that is squared.

PTV AG

311

Chapter 5: User model PrT

In this case, the impedance of a route is related to the minimum impedance, which therefore
measures the relative difference from the optimum. Due to this different approach, the Lohse
model can be used as an alternative to Kirchhoff and Logit. It should be noted, that the Lohse
distribution formula cannot be regarded as a special form of Box-Cox transformation. The
illustration 90 shows the parameterization of the Lohse distribution model on the interface.

Illustration 90: Parameterization of the Lohse distribution model

5.10.5

Lohse model with variable beta in the assignment


The model is described in Schnabel and Lohse (1997) and differs from the Lohse model in that
the distribution parameter is determined depending on the value of the minimum impedance
Rmina. The calculation can be calibrated in more detail when using three additional parameters
, and .
The following approach applies:

Ui = e

R ai

--------- 1
R amin

The following therefore applies:


R ai

--------- 1
R amin

e
a
P i := ---------------------------------------------2
a

j e

Rj

--------- 1
R amin

is calculated according to the following formula:

= ------------------------------------a

1+e

( R min )

The impedance is additionally divided by a scaling divisor.


The variable distribution parameter improves the modeling of the impedance sensitivity.
Identical ratios of impedances are considered differently for short routes compared to long
routes. In the case of two routes with impedances of 5 and 10 minutes or 50 and 100 minutes,
the distribution is not the same.

312

PTV AG

Chapter 5.10: Distribution models in the assignment

The following example illustrates the effect of the distribution model Lohse with variable beta.
The illustration 91 compares different best paths (10 min, 50 min, 150 min, 300 min) with
"detour" alternatives. The distribution to the routes is done on the basis of the sumptuary ratio
and the absolute value of the best path.
For shorter best paths and their alternatives lower detour sensitivity is assumed than for longer
best paths.

Illustration 91: Distribution with variable beta according to the modified Kirchhoff rule
(please refer to Schnabel / Lohse)

The parameters in illustration 91 are described in table 96.

10

0.800

Rmina
0.010

10 min

3.32

10

0.800

0.010

50 min

4.26

10

0.800

0.010

150 min

6.68

10

0.800

0.010

300 min

9.00

Table 96: Parameters for the distribution with variable beta in illustration 91

The illustration 92 shows the parameterization of the Lohse distribution model with variable
beta on the interface.

PTV AG

313

Chapter 5: User model PrT

Illustration 92: Parameterization of the Lohse distribution model with variable Beta

5.10.6

Comparison of the distribution models for the assignment


The effects of the four distribution models (Kirchhoff, Logit, Box-Cox and Lohse) are illustrated
in a simple example. The table 97 to table 99 show three simple cases of a choice between two
alternatives which represent either routes or connections. The model parameters used can be
found in table 100.

Example 1
Alternative 1 has an impedance of 5, alternative 2 an impedance of 10. Thus alternative 2
has a 5-unit higher impedance or a double impedance compared to alternative 1.

Example 2
The impedance of example 1 is increased by 100 units, so that alternative 1 now has an
impedance of 105 and alternative 2 an impedance of 110. This means that alternative 2
thus has a 5-unit higher impedance, as in example 1; however, the impedance ratio is now
0.95 rather than 0.5.

Example 3
The impedance of example 1 is doubled, so that alternative 1 now has an impedance of 50
and alternative 2 an impedance of 100. This now means that alternative 2 has a 50-unit
higher impedance; the impedance ratio is 0.5 as in example 1.

The distribution results demonstrate that in the Logit model the difference of impedances is
decisive, so that examples 1 and 2 result in the same distribution values. The Kirchhoff model,
on the other hand, evaluates the ratio of the impedances and thus generates the same
distribution values for examples 1 and 3. The Box-Cox model allows a combination of Logit
and Kirchhoff, which is also illustrated by the distribution values.
It would seem that the Logit model cannot be recommended for practical use, because the
basis for a passengers choice is different for short and long connections. In practice, it will
certainly make a difference whether a passenger has to travel 5 and 10 minutes (table 97), or
105 and 110 minutes (table 98). In the case of long journeys, the additional 5 minutes are not
as important as in case of short trips. The weaknesses of the Kirchhoff model in the example
in table 99, where one can expect all passengers to chose alternative 1, are not relevant for the
assignment, because connections that differ to such an extent would not be found in the search
at all and would therefore not be real alternatives for the road-user.

314

PTV AG

Chapter 5.11: Incremental assignment

No.

Kirchhoff

Logit

Box-Cox

Lohse

94 %

78 %

86 %

100 %

10

6%

22 %

14 %

0%

Table 97: Distribution for two alternatives with impedance 5 and 10


No.

Kirchhoff

Logit

Box-Cox

Lohse

105

55 %

78 %

62 %

51 %

110

45 %

22 %

38 %

49 %

Table 98: Distribution for two alternatives with impedance 105 and 110
No.

Kirchhoff

Logit

Box-Cox

Lohse

50

94 %

100 %

100 %

100 %

100

6%

0%

0%

0%

Table 99: Distribution for two alternatives with impedance 50 and 100
Kirchhoff

=4

Logit

= 0.25

Box-Cox

= 1, = 0.5

Lohse

=4

Table 100: Model parameters

5.11

Incremental assignment
The incremental assignment procedure models how a network continuously fills up. At the
beginning, road users can use a free network for which exactly one shortest route exists for
every origin/destination relation. The traffic network is then successively loaded. Every step
congests the road network with additional vehicles and, in this way, increases impedance on
the congested links, turns and connectors. Because of the changed impedance, alternative
shortest routes may be found in every step.
The matrix is incrementally assigned to the network in the form of several parts. In this process,
the entire demand is proportionally distributed over the number of iteration steps defined by the
user (maximum 12). The default is an incremental assignment with three iteration steps (33 %,
33 % and 34 %).

PTV AG

The first step determines lowest impedance routes for all required OD-relations of the
current network for either a free network or based on a basic volume.
The defined percentage of the first incremental step of the matrix is then assigned to these
routes.
Subsequently, the new network impedances resulting from these volumes are calculated
via the VD functions.
On this basis, the next iteration step again calculates lowest impedance routes.

315

Chapter 5: User model PrT

This procedure is continued until the entire matrix has been assigned to the network.

If 100% is entered for the first iteration step, Visum calculates the impedances of the current
network and carries out a so-called best-route assignment.

5.11.1

Example of the incremental assignment


The table 101 shows how the incremental procedure works on the example network (see
"Example network for the PrT assignment procedures" on page 213). The 2,000 car trips are
assigned in three iteration steps (50 %, 25 %, 25 %).

Iteration step 1
The shortest route, in the unloaded network, is route 2 with an impedance of 18:00 min. It
is loaded with 50 % of the car trips, i.e. 1,000 car trips.

Iteration step 2
The shortest route in the unloaded network is route 1 with an impedance of 20:50 min. It is
loaded with 25 % of car trips, that is, with 500 car trips.

Iteration step 3
After the second iteration step, route 1 remains the shortest route with an impedance of
29:50 min. It is again loaded with 25 % of the car trips, i.e. with another 500 car trips. It now
has a total of 1,000 car trips.

After the third iteration step, route 3 turns out to have the lowest impedance.
This route, however, is no longer found because all trips have been assigned.

In the example above, the impedance of a route results from the sum of the link impedances of
the route. Additional impedances for connectors and turns are not considered. In addition to
this, it is assumed that impedance results from current travel time tCur, and that current travel
time in turn results from the BPR function with a=1, b=2 and c=1.
LinkNo

316

Type

Length [m]

v0 [km/h]

Capacity

t0 [min]

20

5,000

100

1,200

03:00

20

5,000

100

1,200

03:00

20

5,000

100

1,200

03:00

20

5,000

100

1,200

03:00

20

5,000

100

1,200

03:00

20

5,000

100

1,200

03:00

30

16,000

80

800

12:00

30

5,000

80

800

03:45

10

40

10,000

60

500

10:00

11

40

5,000

60

500

05:00

PTV AG

Chapter 5.11: Incremental assignment

Route

Links of the route

Length [m]

t0 [min]

1+8+9

26,000

18:45

1+2+3+5+6+7

30,000

18:00

10+11+5+6+7

30,000

24:00

LinkNo

Volume

tCur

Step 1 (50%)

Volume

tCur

Step 2 (25%)

Volume

tCur

Step 3 (25%)

1,000

05:05

1,500

07:41

2,000

11:20

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

12:00

500

16:41

1,000

30:45

03:45

500

05:13

1,000

09:37

10

10:00

10.00

10.00

11

05:00

05:00

5:00 AM

Route

Volume

tCur

Step 1 (50%)

Volume

tCur

Step 2 (25%)

Volume

tCur

Step 3 (25%)

20:50

500

29:35

1,000

51:42

1,000

30:30

1,000

33:06

1,000

36:45

30:15

30:15

30:15

Table 101: Example of the incremental assignment (BPR function a=1, b=2, R=tCur)

5.11.2

Procedure of the incremental assignment


The illustration 93 shows the procedure of an incremental assignment.

PTV AG

317

Chapter 5: User model PrT

Input

Demand matrix F
Number of iteration steps N
Demand proportion Pn for each iteration step n = 1, N

n=0
Volume q 0 = 0 or basic volume

Impedance
determination

Determination of impedance R n of all network objects with


the corresponding impedance function.

Route search

Determination of the best route for all relations based on


impedance Rn.

Volume

Assignment of travel demand which results from Pn onto


network objects which are part of the best route.
q n+1 = qn + Pn F

n = n +1
no
Query

n= N ?
yes

End

Determination of impedance Rn of all network objects with


the corresponding impedance function.
Illustration 93: Procedure of the incremental assignment

5.11.3

Input and output attributes of the incremental assignment


To execute the incremental assignment, certain entries have to be made. After calculation, the
results are available in the output attributes and can be displayed in the list view (see User
Manual, Chpt. 12.1, page 1369) or in the network editor (see User Manual, Chpt. 12.2,
page 1400). The table 102 gives an overview of which input attributes have to be maintained.
The table 103 lists the output attributes which store the results of the procedure.

318

PTV AG

Chapter 5.11: Incremental assignment

Table 102: Input attributes for the incremental assignment

The abbreviations represent the following:

PTV AG

x1

The toll by PrTSys has to be inserted manually in the impedance function

(X)

Can be used optionally

(*)

Apart from the parameters which are directly set in the assignment procedure

319

Chapter 5: User model PrT

Table 103: Output attributes of the incremental assignment

5.11.4

Evaluation of the incremental assignment


Lohse (1997) lists the following decisive disadvantages of the incremental assignment
procedure.

5.12

The number and the size of layers (partial matrices) mainly decide on the goodness of the
results. However, there is no procedure to specify optimal layers.
The calculation ends after the specified number of steps has been executed without
checking correspondence between the resulting traffic volume and link impedances.

Equilibrium assignment
The Equilibrium assignment distributes the demand according to Wardrop's first principle.
"Every road user selects his route in such a way, that the impedance on all alternative routes
is the same, and that switching to a different route would increase personal travel time (user
optimum)."
This behavioral hypothesis underlies the unrealistic assumption that every road user is fully
informed about the network state. In transport planning this hypothesis is approved of given a
fundamental methodical advantage of the equilibrium assignment - with quite general

320

PTV AG

Chapter 5.12: Equilibrium assignment

requirements, the existence and uniqueness of the assignment result (expressed in volumes
of the network object) is guaranteed. Moreover, measures for the distance of an approximation
solution from the equilibrium exist, from which an objective termination criterion can be derived
for the procedure, which generally is an iterative problem solution.
The equilibrium assignment determines a user optimum which differs from a system optimum,
as shown in table 104 and table 105.

A user optimum means that the same impedance results for all routes of a traffic relation
between zones i and j (within the scope of calculation accuracy). This results directly from
the condition, that changing to another route is not profitable for any road user (table 104).
A system optimum however means that the total impedance in the network, which is the
product of route impedance and route volume is minimized for all OD pairs. On average,
this procedure leads to shorter journey times per road user, but there are (few) road users
which use routes to serve the general public, with an impedance above average
(table 105).

Route

Links

Volume

tCur [min]

Volume tCur

1+8+9

736

38:19

470:05:53

1+2+3+5+6+7

995

38:21

636:01:21

10+11+5+6+7

269

38:20

171:50:02

Total

2,000

1277:57:17

Table 104: Calculation of the user optimum for the example network
Route

Links

Volume

tCur [min]

Volume tCur

1+8+9

734

37:43

461:46:27

1+2+3+5+6+7

919

37:13

569:58:45

10+11+5+6+7

347

41:13

238:11:24

Total

2,000

1269:56:36

Table 105: Calculation of the system optimum for the example network

5.12.1

Evaluation of the equilibrium assignment

PTV AG

Because the procedure only terminates when all routes of any OD pair are in the balanced
state, the procedure provides more realistic results than the incremental procedure.
For a lower volume/capacity ratio, a similar result is achieved as with best-route
assignment, because the route search does not find new routes. In this case it is
recommended to use an incremental assignment with suitable parameters as initial solution
or the Equilibrium_Lohse procedure.
The computation time required by the equilibrium assignment depends on the volume/
capacity ratio in the network. Because new routes are found in every iteration step for a
strongly saturated network, more computation time is required in this case.
Compared to stochastic assignment procedures (see "Stochastic assignment" on page 365
and "Dynamic stochastic assignment" on page 419) the equilibrium assignment provides
distinct network volumes. Compared to the number of calculated iterations, the gap is a
more objective termination criterion.

321

Chapter 5: User model PrT

5.12.2

Introductive example for the equilibrium assignment


The effectiveness of the equilibrium assignment is described as follows on the basis of the
example described in table 106 and illustration 94. The example analyzes the relation between
traffic zone "village A" and traffic zone "city X".
The total impedance of a route, to keep it simple, results from the sum of link impedances of
the route (see "Impact models" on page 205). Impedances for connectors and turns are not
considered in the route search. In detail, the following assumptions apply:

The impedance of the links is determined from the current travel time tCur. The current
travel time tCur is in turn calculated using the capacity restraint function BPR with a=1, b=2
and c=1.
The access and egress times for the connectors are not considered, that is, they are set to
0 minutes.
Turn penalties are not considered.

With regard to the traffic demand the following applies.

The traffic demand between A-Village and X-City is 2,000 car trips during peak hour.
Capacity and demand refer to one hour.

The example network contains three routes which connect village A and city X.

Route 1 via nodes 10 11 41 40


Route 2 via nodes 10 11 20 21 30 31 40
Route 3 via nodes 10 12 21 30 31 40

Route 1 mainly uses country roads and is 26 km long. It is the shortest route. Route 2 is 30 km
long. It is the fastest route because the federal road can be traversed at a speed of 100 km/h
if there is free traffic flow.
Route 3 which is also 30 km long is an alternative route which only makes sense if the federal
road is congested.

322

PTV AG

Chapter 5.12: Equilibrium assignment

village A
1

10

10

11

12

11

41

20

40

21

30

city X

31

Illustration 94: Example network for the equilibrium assignment


LinkNo From Node To Node
11

Type

Length [m]

Capacity [car units/h]

v0-PrT [km/h]

10

20 Federal road

5,000

1,200

100

11

20

20

20 Federal road

5,000

1,200

100

21

20 Federal road

5,000

1,200

100

20

40

90 Rail track

10,000

21

30

20 Federal road

5,000

1,200

100

30

31

20 Federal road

5,000

1,200

100

31

40

20 Federal road

5,000

1,200

100

11

41

30 Country road

16,000

800

80

40

41

30 Country road

5,000

800

80

10

10

12

40 Other roads

10,000

500

60

11

12

21

40 Other roads

5,000

500

60

Table 106: Example network for the equilibrium assignment

As a result, the assignment provides values from table 107 for the three routes (PrT paths).
Route

tCur

Impedance

Volume(AP)

46min 39s

2,798

1,157.488

46min 34s

2,794

618.079

46min 12s

2,772

224.432

Table 107: Assignment results for the three PrT paths

PTV AG

323

Chapter 5: User model PrT

The most important assignment results for the links are displayed in table 108.
Link tCur

Impedance Volume(AP) Saturation PrT (AP) VehicleHr(tCur) VehKmTravelled


PrT

11min
40s

700

1,908

170 370h 54min 19s

9,537.839

5min 47s

347

1,157

96 111h 43min 15s

5,787.442

5min 47s

347

1,157

96 111h 43min 15s

5,787.442

7min 48s

468

1,450

126 188h 29min 38s

7,249.603

7min 48s

468

1,450

126 188h 29min 38s

7,249.603

7min 48s

468

1,450

126 188h 29min 38s

7,249.603

26min
35s

1,595

750

110 332h 23min 38s

12,001.270

8min 19s

499

750

110 103h 52min 23s

3,750.397

10

15min
12s

912

292

72

74h 3min 56s

2,924.321

11

7min 36s

456

292

72

37h 1min 58s

1,462.161

Table 108: Assignment result at the links

5.12.3

Input and output attributes of the equilibrium assignment


To execute the equilibrium assignment, certain entries have to be made. After calculation, the
results are available in the output attributes and can be displayed in the list view (see User
Manual, Chpt. 12.1, page 1369) or in the network editor (see User Manual, Chpt. 12.2,
page 1400). The table 109 gives an overview of which input attributes have to be maintained.
The table 110 lists the output attributes which store the results of the procedure.

324

PTV AG

Chapter 5.12: Equilibrium assignment

Table 109: Input attributes of the equilibrium assignment

The abbreviations represent the following:

PTV AG

x1

Toll PrTSys has to be inserted manually in the impedance function

Generally possible, however not recommended

(*)

Apart from the parameters which are directly set in the assignment procedure

325

Chapter 5: User model PrT

Table 110: Output attributes of the equilibrium assignment

If you use metric units, enter the long lengths for kilometers and speeds in km/h. For imperial
units enter the long lengths in miles and speeds in mph.

5.12.4

Procedure of the equilibrium assignment


The equilibrium state calculation can be formulated as an optimization problem with a convex
objective function and linear secondary conditions.
qa

min!

aE

Ra ( x ) dx
0

q ijr > 0, ijr

r qijr = qij, ij
ijr : a P
a E

q ijr = q a, a
ijr

qa

aE

qa =

i qiu j quj = Du Ou, u

The following applies:

326

E
qa

the set of all edges in a network and a one of these edges

Ra(x)

the impedance of object a with volume x (monotonically increasing in x)

qij

the total demand (number of trips) from zone i to zone j

qijr

volume of route r from zone i to zone j

Pijr

route r from zone i to zone j

E+u

the set of the incoming edges at node u

volume of object a

PTV AG

Chapter 5.12: Equilibrium assignment

E-u

the set of the outgoing edges at node u

Du

destination traffic at node u

Ou

origin traffic at node u

In Visum, edges are all links, turns and connectors, whereas nodes are zones and network
nodes.
The objective function shows that the sum of impedances of all edges is minimized. The
secondary conditions indicate the following (from top to bottom).

All path volumes have to be positive.


The volumes of all paths from zone i to j have to add up from the total demand from i to j.
The volume of an edge results from the sum of volumes of all paths, which contain this
edge.
Flow conservation applies at each node. When a node corresponds with a zone, the
difference between the volumes of all incoming edges and the volumes of all outgoing
edges have to correspond exactly with the difference between the destination and origin
traffic. There is no origin and destination traffic at network nodes, thus the difference must
be zero.

Due to the non-linear objective function, the optimization problem is not solved directly but
iteratively. Because of the monotonicity of the impedance function, the minimum is reached, so
that starting with a starting solution between the alternative paths, a movement i-j is shifted, so
that the paths all have the same impedance.
During the equilibrium assignment the steps showed in illustration 95 will be made.

PTV AG

327

Chapter 5: User model PrT

Input

Loaded network (starting solution) with loaded routes r


Maximum number of iteration steps N
Maximum absolute deviation of impedance E abs
Maximum relative deviation of impedance E rel

n =0

Network
balancing

Balance the volumes of all routes r for all OD pairs ij so


that the impedance R rij of the routes is:
| min. Rij max. Rij |< Eabs or
max. Rij / min. Rij < 1 + Erel

n = n +1

Route search

Query

Determination of the best routes for all relations i-j based


on impedance R(n) .

New routes found and


n < N and
relative gap > max. permitted relative gap?

yes

no
End
Illustration 95: Procedure of the equilibrium assignment

Based on an assignment result from a previously calculated assignment or an incremental


assignment (by default) as a starting solution, the state of balance is reached by multiple step
iteration. In the inner iteration step, two routes of a relation are brought into a state of
equilibrium by shifting vehicles. These iteration steps are carried out for all relations until all
relations are in a state of balance. Every shift of vehicles from one route to another has an
immediate effect on the impedances of the traversed network objects.
The outer iteration step checks if new routes with lower impedance can be found as a result of
the current network state. If this is the case for at least one relation, another state of balance
must be calculated.
The following termination condition applies. A state of balance has been reached if the inner
iteration step did not need to shift vehicles, and no new routes were later found by the external
iteration step.
Also the convergence criterion Gap can be used as termination condition.

328

PTV AG

Chapter 5.12: Equilibrium assignment

Network balancing
The procedure of the network balancing is displayed in illustration 96.

Input

Route search

Pair balancing

Update
impedance

Query

Volume q r of each route r,


Impedance Rr of each route r,
Maximum absolute deviation of impedance Eabs
Maximum relative deviation of impedance Er el

Select two routes:


Route r1: Route with minimal impedance R1
Route r2: Route with maximum impedance R2

Balance the volume of routes r1 and r 2 in such a way that


the impedance of the routes is:
| R1 R2 |< Eabs or
1 Er el < R1 / R2 < 1 + Er el
If the volume of route r 1 or r2 is 0 after balancing, delete
route.

Update impedance of all network objects whose volume


has changed.

Is the following condition fulfilled for the route with the


minimum impedance R1, and the route with the maximum
impedance R2?
| R1 R2 | < Eabs or
R2 / R1 < 1 + Er el

no

yes
End

Network balancing completed

Illustration 96: Procedure of the network balancing for an OD pair in the equilibrium assignment

Termination criterion
Visum cancels the iteration process for calculating the equilibrium, if one of the following
conditions has been fulfilled:

PTV AG

Network balancing has been achieved, this means a permitted deviation of impedances of
the routes compared in pairs was reached or undercut.
The specified number of external iterations was reached without a network balancing being
reached (in very highly loaded networks it is possible that the permitted deviations which
were specified do not result in a state of balance because only integer vehicles are shifted).
The convergence criterion Max. gap is reached or undercut.

329

Chapter 5: User model PrT

5.12.5

In case of an equilibrium assignment with blocking back model the maximum deviation was
reached or undercut (see "Blocking back model" on page 292). The procedure is cancelled
if the congestion volume values and the congestion wait times of two external iterations
deviate by the max. rel. difference or less.

Calculation example for the equilibrium assignment


Route

Volume

tCur [min]

Starting solution

1,000

51:42

Routes 1 + 2 are known

1,000

36:45

30:15

Network balancing 0

776

41:54

Routes 1 + 2

1,224

41:56

33:22

Iteration step 1: route search finds route 3


Network balancing 1

649

36:25

Routes 1 + 3

1,224

42:58

127

36:23

Max. imp. route = 2, Min. imp. route = 3


Network balancing 2

649

35:15

Routes 2 + 3

1,067

40:17

284

40:15

Max. imp. route = 2, Min. imp. route = 3


Network balancing 3

734

38:09

Routes 1 + 2

982

38:10

277

38:51

Max. imp. route = 3, Min. imp. route = 1


Network balancing 4

741

38:27

Routes 1 + 3

982

38:07

277

38:31

Max. imp. route = 3, Min. imp. route = 2


Network balancing 5

741

38:30

Routes 2 + 3

990

38:14

269

38:15

Max. imp. route = 1, Min. imp. route = 2


Network balancing 6

736

38:19

Routes 1 + 2

995

38:21

269

38:20

Table 111: Example equilibrium procedure (BPR function a=1, b=2)

330

PTV AG

Chapter 5.13: Linear User Cost Equilibrium (LUCE)

The table 111 shows how the equilibrium procedure works on the example network (see
"Example network for the PrT assignment procedures" on page 213). The volume determined
with the incremental procedure is used here as the initial solution (see "Example of the
incremental assignment" on page 316). This starting solution encompasses two routes, each
loaded with 1,000 car trips. The specified absolute deviation is a value of five impedance units,
and the relative deviation is specified as being 0.1 %. Based on the starting solution, the
following steps are then carried out.

Network balancing for starting solution


The volumes of the routes 1 and 2 are changed in such way that the deviation of the two
route impedances is below the specified deviation. With a volume of 776 respectively 1,224
vehicles for routes 1 and route 2, this is guaranteed.

Route search for iteration step 1


After network balancing of routes 1 and 2, the shortest path search of the first iteration step
determines route 3.

Network balancing for iteration step 1


The three routes are balanced in pairs until the impedance of all routes accords with the
specified deviation.
This is the case in the example if one of both conditions applies:

The absolute deviation between maximum and minimum impedance is smaller than 5
seconds.
The relative deviation between the maximum and minimum impedance is less than
0.1 %.
Network balancing by pairs always changes the volumes of the route with the minimum
impedance and the route with the maximum impedance.
Route search for iteration step 2
No new route is found, the equilibrium procedure terminates.

5.13

Linear User Cost Equilibrium (LUCE)


Similarly to origin-based methods, the problem is partitioned by destinations in the LUCE
procedure. The main idea is to seek at each node a user equilibrium for the local route choice
of drivers directed toward the destination among the arcs of its forward star.. The travel
alternatives that make up the local choice sets are the arcs that belong to the current bush. A
bush is an acyclic sub-graph that connects each origin to the destination at hand. The cost
functions associated to these alternatives express the average impendence to reach the
destination linearized at the current flow pattern.
The unique solutions to such local linear equilibria in terms of destination flows, recursively
applied for each node of the bush in topological order, provide a descent direction with respect
to the classical sum-integral objective function. The network loading is then performed through
such splitting rates, thus avoiding explicit path enumeration.

PTV AG

331

Chapter 5: User model PrT

5.13.1

Mathematical formulation and theoretical framework


The transport network is represented through a directed graph G = (N, A), where N is the set of
the nodes and A NN is the set of the arcs. In the graph, the nodes represent the zone
centroids and the road intersections (Visum network nodes), while the arcs represent the links
and the connectors. When turns with impendence or restrictions are introduced in the network
model, then the node is properly exploded, so that such turns are associated to specific or no
arcs of the graph.
We adopt the following notation:
fij

Total flow on arc ijA, generic element of the (|A|1) vector f

cij

Cost of arc ijA, generic element of the (|A|1) vector c

cij(fij)

Cost function of arc ijA

ZN
Dod

Set of the zone centroids

Kid

Set of the acyclic paths between node iN and destination dZ

K = oZ dZ Kod is the set of paths available to road users

ij

Demand flow between origin oZ and destination dZ, generic element of the (|Z|21) vector
D, that is the demand matrix in row major order

ijk = 1, if arc ijA belongs to path k, and 0, otherwise for kK, this is the generic element
of the (|A||K|) matrix D

odk

odk is 1, if path kK connects origin oZ to destination dZ (i.e. kKod), and 0, otherwise


this is the generic element of the (|Z|2|K|) matrix L

Fk

Flow on path kK, generic element of the (|K|1) vector F

Ck

The cost of path k for kK this is the generic element of the (|K|1) vector C

Wid

Minimum cost to reach destination dZ from node iN

Set of real numbers

|S|

Cardinality of the generic set S

There are two fundamental relations between flow variables. The flow on arc ijA is the sum
of the flows on the paths that include it:
fij = kK ijk Fk

The travel demand between origin oZ and destination dZ must be equal to the sum of the
flows on the paths that connect them:
kKod Fk = Dod

Moreover, all path flows must satisfy non-negativity constraints.


As usual, we assume additive path costs, i.e. the impendence Ck associated by users to a
given path k is the sum of the costs on the arcs that belong to it:
Ck = ijA ijk cij

(6)

By definition, the minimum cost to reach destination dZ from node iN is the cost of any
shortest path that connects them:

332

PTV AG

Chapter 5.13: Linear User Cost Equilibrium (LUCE)

Wid = min{Ck : kKid}

(7)

In this case, the traffic assignment problem can be formalized through the following program:

min (f) =

c
(
x
)
d
x
:
f

ij A ij

f ij

(8)

where

{f|A|: f = F, F} is the set of feasible arc flows

{F|K|: F 0, F = D} is the set of feasible path flows

To ensure the existence and uniqueness of the solution to problem (8) we assume that:
cij(fij) is non-negative, continuous, strictly monotone increasing;
Kod is non-empty;
Dod is non-negative.

Problem (8), which is convex, can also be expressed in terms of path flows as follows:

k K ij Fk

min (F) =
c
(
x
)
d
x
:
F

(9)

ij

ij

f=0

where, although the solution uniqueness does not hold anymore, the convexity of the
mathematical program is preserved, implying that any descent algorithm in the space of path
flows will provide one of the global solutions, which then make up a convex set.
k

The relevance of program (9) to traffic assignment stands from the fact that, in the case of
additive path costs, its first order (necessary) conditions coincide with the following formulation
of the deterministic user equilibrium based on Wardrop's Principles, for each oZ and dZ:
kKod

(10.1)

Ck Wo ,

kKod

(10.2)

Fk 0,

kKod

(10.3)

Fk (Ck - Wod) = 0,
d

kKod Fk = Dod

(10.4)

Based on (10.1) to (10.4)

all used paths (Fk > 0) have minimum cost (Ck = Wod);

any unused path (Fk = 0) has not a lower cost (Ck Wod).

We have a user equilibrium if conditions (10.1) to (10.4) hold jointly for each OD couple, while
considering that each path cost Ck is a function (potentially) of all the path flows F through the
arc cost function:
Ck = ijA ijk cij(kK ijk Fk), in compact form C = T c(F)

(11)

Since the gradient of (F) C = T c(F), by linearizing the objective function of problem (9) at
a given a point F, for X F we obtain:

PTV AG

333

Chapter 5: User model PrT

(X) = (F) + CT(X-F) + o(||X-F||).

(12)

From equation (12) we recognize that a direction E-F is descent if and only if:
CT(E-F) < 0.

(13)

In other words, to decrease the objective function and maintain feasibility we necessarily have
to shift path flows getting a lower total cost with respect to the current cost pattern, i. e. move
the current solution from F towards an E such that CTE < CTF, where C = Tc(F). The
necessity derives from the convexity of the problem, since in this case at any point X such that
CT(X-F) > 0 we have: (X) > (F).
This approach to determine a descent direction can be applied to each OD pair separately, to
each destination, or to the whole network jointly. Based on the above general rule, setting the
flow pattern E by means of an all-or-nothing assignment to shortest paths clearly provides a
descent direction. If we adopt such a direction for all OD pairs of the network jointly, and apply
along it a line search, we obtain the well known Frank-Wolfe algorithm. However, at equilibrium
each OD pair typically uses several paths, implying that any descent direction that loads a
single path is intrinsically myopic; in fact such algorithms tail badly.
Once we get a feasible descent direction E-F, since is convex, we can move the current
solution along the segment F+(E-F) and take a step (0,1] such that the objective function
of problem (9), redefined as () = (F+(E-F)), is sufficiently lowered. In this respect,
knowing that is C1 and convex, and thus also is such, several methods are available to
determine an which minimizes (). Visum uses an Armijo-like search and determines the
largest step = 0.5k, for any non-negative integer k, such that
(0.5k)/ < 0.

(14)

This method requires to compute the directional derivative of the objective function:
()/ = [c((F+(E-F)))]T[(E-F)],

(15)

which implies to evaluate the arc costs at the candidate flows F+(E-F) and then the
difference between the corresponding total costs obtained with the flows E and F. If such total
costs with E are smaller than those with F, then ()/ is negative so that the optimal solution
is more toward E, and vice versa.

5.13.2

Local user equilibrium


In this section we present a new method to determine a descent direction, which is based on
local shifts of flows that satisfy the total cost lowering rule and exploits the inexpensive
information provided by the derivatives of the arc costs with respect to arc flows.
To grasp immediately the underlying idea, we can refer to the simplest network where one OD
pair with demand D is connected by two arcs with cost function c1(f1) and c2(f2), respectively.
At the current flow pattern f = (D/2, D/2) it is c1 < c2 (see illustration 97), so that an all or nothing
approach would lead to a descent direction (D, 0), which is far away from the equilibrium f*
(gray circle in the Figure). The LUCE approach, instead, is to consider the first order
approximations of the cost functions at the current flow pattern, i.e. ca + ca(fa)/fa (fa - fa), and
determine a user equilibrium e among these lines (white circle in the Figure): this descent
direction efficiently approaches the equilibrium f*. In most cases =1 can be taken as the new
iterate with a step one.

334

PTV AG

Chapter 5.13: Linear User Cost Equilibrium (LUCE)

Illustration 97: Linear User Cost Equilibrium between two paths

To reach any destination dZ, at the equilibrium only shortest paths are utilized. Given that the
arc cost functions are strictly monotone increasing, they make up an acyclic [*1] sub-graph of
G, i.e. a (reverse) bush rooted at d. At strict monotonicity, any arc cost can be null only if its flow
is such. However, in Visum links and connectors may have null impedance, producing twofold
consequences: a) the corresponding arc cost functions loose strict monotonicity, so that
uniqueness is not guaranteed anymore. b) The sub-graph made-up by arcs with positive
destination flows at some of the possible equilibria may be cyclic. The implementation of LUCE
in Visum specifically addresses this issue and converges to one among the possible equilibria
by forcing an acyclic solution and equally splitting the flow among all alternatives with minimum
cost in presence of uncongested sub-paths. This special case is not further dealt with below.
On this base, when seeking a descent direction, in the following we will limit our attention to the
current bush B(d) and introduce an updating mechanism to make sure that eventually any
shortest path will be included into it; equilibrium is actually only attained this way. Let us focus
on the local route choice at a generic node iN for road users directed to destination dZ.
For the topology of the bush we will use the following notation:
FSB(i, d) = {jN: ijB(d)} the forward star of node iN made-up by nodes that can be
reached from it through arcs belonging to the current bush B(d) of
destination dZ
BSB(i, d) = {jN: ijB(d)} the backward star of node iN made-up by nodes that can reach it
through arcs belonging to the current bush B(d) of destination dZ

For the flow pattern we will use the following notation:


fijd

current flow on arc ijA directed to destination dZ


By construction it is fijd = 0 for each jFSB(i, d);
moreover it clearly is: fij = dZ fijd

fid = jFSB(i, d) fijd

current flow leaving node iN to destination dZ

yijd

yijd = fijd / fid current flow proportion on arc ijA directed to destination dZ, if
fid > 0, yijd = 0 else

eijd

PTV AG

descent direction, in terms of flow on arc ijA directed to destination dZ

335

Chapter 5: User model PrT

eid

descent direction, in terms of flow leaving node iN directed to destination dZ

eijd = eijd / eid

descent direction, in terms of flow proportion on arc ijA directed to destination


d Z

For the cost pattern we will use the following notation:


Cid

average cost to reach destination dZ from node iN

gij

Cost derivative of arc ijA

Gid

Derivative of the average cost to reach destination dZ from node iN

The average cost Cid is the expected impendence that a user encounters by travelling from
node iN to destination dN. Here it is defined recursively based on the current flow pattern:
if fid > 0, then Cid = jFSB(i, d) yijd (cij + Cjd), else

(16.1)

Cid = min{cij + Cjd: jFSB(i, d)},

(16.2)

as if drivers utilize paths accordingly with the current flow proportions. In the following we
assume that the cost function cij(fij) is continuously differentiable for each arc ijA:
gij = cij(fij) / fij

(17)

Under the assumption that an infinitesimal increment of flow leaving node iN directed towards
destination dZ would diverge accordingly with the current flow proportions, we have:
if fid > 0, then Gid = Cid / fid = jFSB(i, d) yijd 2 (gij + Gjd), else

Gid

jFSB(i, d) [Cid

= cij +

Cjd]

(gij +

Gjd)

jFSB(i, d) [Cid

= cij +

(18.1)
Cjd],

(18.2)

where the derivatives gij + Gjd are scaled by the shareyijd of fid utilizing arc ij and then passing
through node j, that jointly with the flow proportion involved in the averaging yields the square
yijd 2.
The average costs and their derivatives can be computed by processing the nodes of the bush
in reverse topological order according to d, starting fromCdd = Gdd = 0.
We now address the local user equilibrium for the eid drivers directed to destination dZ, whose
available alternatives are the arcs of the bush exiting from node iN. To each travel alternative
we associate the cost function:
vijd(eijd) = (cij + Cjd) + (gij + Gjd) (eijd - yijd eid),

(19)

resulting from a linearization at the current flow pattern of the average cost encountered by a
user choosing the generic arc ij, with jFSB(i, d).
This problem can be formulated, in analogy to (10.1) to (10.4), by the following system of
inequalities:
eijd [vijd(eijd) - Vid] = 0,

jFSB(i, d),

(20.1)

vijd(eijd) Vid,

jFSB(i, d),

(20.2)

eijd 0,

336

jFSB(i, d),

(20.3)

PTV AG

Chapter 5.13: Linear User Cost Equilibrium (LUCE)

jFSB(i, d) eijd = eid,

(20.4)

where we denote:
Vid

local equilibrium cost to reach destination dZ from node iN;

vijd

Cost of the local alternative jFSB(i, d), to reach destination dZ from node iN via j.

If eid = 0, the solution to the above problem is trivially: eijd = 0, for each jFSB(i, d). Consider
then the case where eid > 0. To improve readability, problem (20.1) to (20.4) can be rewritten
as:
xj (aj + bj xj - v) = 0,

jJ,

(21.1)

aj + bj xj v,

jJ,

(21.2)

xj 0,

jJ,

j xj = 1,

(21.3)
(21.4)

where:
J
aj

{(i, j, d): jFSB(i, d)}

bj

(gij + Gjd) eid

xj

eijd / eid

Vid

(cij + Cjd) - (gij + Gjd) eid yijd

Applying the usual Beckmann approach we can reformulate the equilibrium problem (21.1) to
(21.4) as the following quadratic program:
min{jJ 0 xj(aj + bj x) dx: xX} = min{jJ aj xj + 0.5 bj xj2: xX},

(22)

where X is the convex set of all vectors satisfying the feasibility conditions (21.3) and (21.4).
The gradient of the objective function is a vector with generic entry aj + bj xj, and then the
Hessian of the objective function is a diagonal matrix with generic entry bj. Therefore, if all
entries bj are strictly positive, the Hessian is positive definite and problem (22) has a unique
solution. In order to ensure such a desirable property we assume without loss of generality that
the derivates gij are strictly positive for all arcs ijA. Since the arc cost functions are strictly
monotone increasing, gij can be zero only if also fijd is zero. Therefore, at the equilibrium bj = 0
implies xj = 0. In practice we will substitute any gij = 0 with a small .
To solve problem (21.1) to (21.4) we propose the following simple method. In order to satisfy
condition (21.1), either it is xj = 0, and in this case condition (21.2) requires aj v, or it is aj + bj
xj = v. Let J0 J be the set of alternatives with zero flow, that is J0 = {jJ: xj = 0}. For any given
J0 the solution is immediate, since from (21.4) it is jJ (v - aj) / bj = 1; therefore we have:
v = (1 + jJ\J0 aj / bj) / (jJ\J0 1 / bj),

PTV AG

(23.1)

xj = (v - aj) / bj,

jJ\J0,

(23.2)

xj = 0,

jJ0.

(23.3)

337

Chapter 5: User model PrT

The flow proportions provided by (23.1) to (23.3) implicitly satisfy (21.4). But to state that the
chosen J0 yields the solution of problem (21.1) to (21.4), we still must ensure the following
conditions: aj < v, for each jJ\J0 (as required by (21.3), since xj = (v - aj) / bj > 0), and aj v, for
each jJ0 (as required by (21.2), since xj = 0). This implies that at the solution the value of v
resulting from (23.1) must partition the set J into two sub-sets: the set J0, made up by the
alternatives j such that aj v; and its complement J\J0, made up by the alternatives j such that
aj < v.
At a first glance the problem to determine the set J0 of alternatives with zero flow may seem to
be combinatorial. However, this is not the case. The equation (23.1) can be rewritten as a
recursive formula. It then shows the effect of removing an alternative k from the set J0:
v[J0\{k}] = (v[J0] jJ\J0 1 / bj + ak / bk) / (jJ\J0 1 / bj + 1 / bk).

(24)

The right hand side of (24) can be interpreted as an average between v[J0] and ak with the
positive weights jJ\J0 1 / bj and 1 / bk. Therefore, the local equilibrium cost increases by
removing from J0 any alternative kJ\J0, for which ak is higher than the current value v[J0]. Vice
versa it decreases by adding such alternatives to J0. Consequently, the correct partition set J0
can be simply obtained by adding iteratively to an initially empty set each alternative jJ\J0
such that aj > v, i.e. each alternative for which (23.2) yields a negative flow proportion.

5.13.3

Descent direction
To obtain a complete pattern of arc flows ed for a given destination dZ consistent with the local
user equilibrium we simply have to solve problem (20.1) to (20.4) at each node iN\{d}
proceeding in topological order, where the node flow is computed as follows:
eid = jBSB(i, d) ejid + Did

(25)

We have shown that a given direction is descent if, and only if (13) applies (see "Mathematical
formulation and theoretical framework" on page 332). In terms of arc flows directed to
destination dZ, the following results:
ijA cij (eijd - fijd) < 0,

(26)
d

expressing that the shift of flow from f to e must entail a decrease of total cost with respect to
the current cost pattern. The proof that the proposed procedure provides a descent direction
goes beyond the scope of this description. For more detailed information, please refer to
Gentile G., 2009.
In the following we present an example showing the computation of the descent direction
provided by the LUCE algorithm. We consider the graph of the Braess paradox, with 4 nodes
and 5 arcs.

338

PTV AG

Chapter 5.13: Linear User Cost Equilibrium (LUCE)

Illustration 98: Numerical example of the procedure to obtain the descent direction

The arc cost function is cij = Tij + Qij fij2, so that its derivative is gij = 2 Qij fij.
There is only one destination d = 4, and two origins with travel demand D14 = 9 and D24 = 2. We
consider an initial flow pattern where all available paths, the 3 routes from 1 to 4 and the 2
routes from 2 to 4, are equally used by each OD pair. In this case it is fij = fijd and the bush is
the entire network.
After we evaluate at the current flow pattern the arc costs and their derivatives, we can
compute for each node i the average cost Cid and its derivative Giditeratively starting from the
destination, where Cdd = Gdd = 0, and proceeding in reverse topological order. To this aim we
apply the formulas:
Cid = jFSB(i, d) yijd (cij + Cjd), Gid = jFSB(i, d) yijd 2 (gij + Gjd).

While the computation for node 3 is trivial, since its forward star is a singleton, for node 2 we
have:
C24 = y234 (c23 + C34) + y244 (c24 + C44) = 0.5 (21 + 52) + 0.5 (42 + 0) = 57.5,
G24 = y234 2 (g23 + G34) + y244 2 (g24 + G44) = 0.52 (8 + 14) + 0.52 (16 + 0) = 9.5,

and for node 1 it is:


C34 = y134 (c13 + C34) + y124 (c12 + C24) = 0.33 (29 + 52) + 0.66 (41 + 57.5) = 92.7,
G34 = y134 2 (g13 + G34) + y124 2 (g12 + G24) = 0.332 (12 + 14) + 0.662 (12 + 9.5) = 12.4.

PTV AG

339

Chapter 5: User model PrT

Illustration 99: Numerical example of the procedure to obtain the descent direction

Now we can compute for each node i the node flows eid and the arc flows eijd iteratively by
proceeding in topological order.
To this aim we shall focus on the local route choice of the eid users, whose available
alternatives are the arcs of the bush exiting from node i. To each travel alternative we
associate the cost function:
vij(eijd) = (cij + Cjd) + (gij + Gjd) (eijd - yijd eid),

resulting from a linearization at the current flow pattern of the average cost encountered by a
user choosing arc ij, and we look for an equilibrium. We have shown that the latter can be
determined using the following formulas:
Vid = (1 + jJ aijd / bijd) / (jJ 1 / bijd), eijd = eid (Vid - aijd) / bijd,

where: aijd = (cij + Cjd) - (gij + Gjd) eid yijd, bijd = (gij + Gjd) eid. J is set initially to the forward
star FSB(i, d); if some eijd results to be negative, then it is set to zero, j is removed from J and
the computation is repeated.
We start then with node 1, whose node flow is e14 = D14 = 6:
a134 = (c13 + C34) - (g13 + G34) e14 y134 = (29 + 52) - (12 + 14) 9 0.33 = 3
a124 = (c12 + C24) - (g12 + G24) e14 y124 = (41 + 57.5) - (12 + 9.5) 9 0.66 = -30.5,
b134 = (g13 + G34) e14 = (29 + 14) 9 = 387.
b124 = (g12 + G24) e14 = (41 + 9.5) 9 = 454.5.
V14 = (1 + a134/b134 + a124/b124) / (1/b134 +1/b124) = (1+ 3/387-30.5/454.5) / (1/387+1/454.5) = 196.6,
e134 = e14 (V14 - a134) / b134 = 9 (196.6 - 3) / 387 = 4.5,
e124 = e14 (V14 - a124) / b124 = 9 (196.6 + 30.5) / 454.5 = 4.5.

Then we go on with node 2, whose node flow is e24 = e124 + D24 = 4.50 + 2 = 6.5:
a234 = (c23 + C34) - (g23 + G34) e24 y234 = (21 + 52) - (8 + 14) 6.5 0.5 = 1.5,
a244 = (c24 + C44) - (g24 + G44) e24 y244 = (42 + 0) - (16 + 0) 6.5 0.5 = -10,

340

PTV AG

Chapter 5.13: Linear User Cost Equilibrium (LUCE)

b234 = (g23 + G34) e14 = (8 + 14) 6.5 = 143.


b244 = (g24 + G44) e14 = (16 + 0) 6.5 = 104,
V24 = (1 + a234/b234 + a244/b244) / (1/b234 +1/b244) = (1 +1.5/143 -10/104) / (1/143+1/104) = 55.1,
e234 = e24 (V24 - a234) / b234 = 6.5 (55.1 - 1.5) / 143 = 2.43,
e244 = e24 (V24 - a244) / b244 = 6.5 (55.1 + 10) / 104 = 4.07,

Finally, we consider node 3, whose volume is e34 = e134 + e234 + D34 = 4.5 + 2.43 + 0 = 6.93:
Since there is only one alternative, the following applies: e344 = e34 = 6.93. Only for completeness we compute V34 as follows:
V34 = (c34 + C44) + (g34 + G44) (e344 - e34 y344) = (52 + 0) + (14 + 0) (6.55 - 6.93 1) = 46.7.

The flow pattern we have just found is a descent direction because we have:
ijA fijd cij = 949 > ijA eijd cij = 897.

The illustration 98 represents the AON assignment to shortest paths (marked by *). The
illustration 99 displays the equilibrium flow and cost pattern (marked by *). It can be seen that
one single iteration of the proposed descent direction allows a substantial step towards the
solution.

5.13.4

Assignment algorithm
Below we provide a pseudo code of the procedure within the framework of an assignment
algorithm.

function LUCE
f = 0
initialize the solution flows to zero
perform n iterations
for k = 1 to n
for each destination d
for each dZ
for each ijA
compute arc costs and their derivatives
cij = cij( fij)
gij = max{cij( fij)/fij, }
if fid > 0 then yijd = fijd / fid else yijd = 0
B(d) =B(B(d), c, f)
initialize or modify the current bush
Cd d = 0
the average cost of the destination is zero
Gdd = 0
so its derivative
for each i:ijB(d) in reverse topological order for each node i d in the bush
if fid > 0 then
Cid = jFSB(i, d) yijd (cij + Cjd)
compute the node average cost to d
and its derivative
Gid = jFSB(i, d) yijd 2 (gij + Gjd)
else
Cid = min{cij + Cjd: jFSB(i, d)}
Gid = jFSB(i, d) [Cid = cij + Cjd] (gij + Gjd) / jFSB(i, d) [Cid = cij + Cjd],
d
e = 0
reset the arc and node flows to d
for each oZ
load on the origins the demand to d
eod = Dod
for each i:ijB(d) in topological order for each node i d in the bush
J = FSB(i, d)
initialize the set of arcs with positive flow
= 0
until = 1 do
PTV AG

341

Chapter 5: User model PrT

=1

Vid = [eid + jJ (cij + Cjd) / (gij + Gjd) - eidyijd] / jJ 1/(gij + Gjd)


for each jJ
eijd = Vid / (gij + Gjd) - (cij + Cjd) / (gij + Gjd) + eidyijd
if eijd < 0 then
eijd = 0
J = J \ { j}
remove ij from the set of arcs with positive flow
=0
then repeat the procedure
for each jJ
propagate the arc flows to the head node flows
ejd = ejd + eijd
= 1
if k > 1 then
armijo step
until ijA cij( fij + (eijd - fijd)) (eijd - fijd) < 0 do = 0.5
update arc flows
for each ijA
fij = fij + (eijd - fijd)
fijd = fijd + (eijd - fijd)

The bush of each destination dZ is initialized with the set of efficient arcs that bring closer to
the destination, where the minimum costs are evaluated at zero flow. At the generic iteration,
any non-efficient arc on the bush carrying no destination flow is removed from it, while any arc
that would improve shortest paths on the bush is added to it, if its reverse arc does not carry
destination flow. If the resulting sub-graph is acyclic, then it is substituted to the current bush
of that destination. Since the LUCE algorithm tends to an equilibrium on the bush, eventually
the flow on non-efficient paths disappears and the bush can be properly modified.
Note that, beside the initialization of the bushes, the LUCE algorithm does not require shortest
path computations, but only simple visits of the bushes.

5.13.5

Input and output attributes of the equilibrium assignment (LUCE)


For the equilibrium assignment (LUCE), the same input attributes are required as for the
equilibrium assignment (table 109).
After calculation, the results are available in the output attributes and can be displayed in the
list view (see User Manual, Chpt. 12.1, page 1369) or in the network editor (see User Manual,
Chpt. 12.2, page 1400).
Tip: This hint might help to reduce the LUCE run time by means of specific network modeling.
Internally, LUCE has to explode a node to generate several sub-nodes and connecting links
between these sub-nodes, if the turns via the node have different impedances of if some of
these turns are not open. Due to this, the graph on which the procedure works will be
extended which again means an increase in the run time. If you do not want to model the
turns explicitly in your network model, make sure that also the U-turns are permissible for all
private transport systems. Otherwise, Visum has to explode all nodes because of the blocked
U-turns. By default, all turns are open in Visum, U-turns included. If there are no aspects that
contradict, you should open the blocked U-turns in your network, too. For more details
regarding the transport system set recalculation at turns and main turns, please refer to the
given chapters: (see User Manual, Chpt. 2.13.6.4, page 274) and (see User Manual, Chpt.
2.20.6.4, page 357). This will not have any negative effect on the created routes, since Uturns are never included in loaded routes as long as none of the turns has been modeled
explicitly.

342

PTV AG

Chapter 5.13: Linear User Cost Equilibrium (LUCE)

5.13.6

Persistent storage of bushes


For each demand segment, the routes and route volumes are stored as bushes in the version
file.
Bushes are regarded for the following operations on paths:

Skim matrix (also for a freely definable skim) in case of route-based assignments:
for the Minimum weight, always the shortest path is used for calculation
for the Mean over route volumes weight, the shortest path is used only if the OD pair
is not in the bush; otherwise, the skim data is weighted with the volumes of the edges
from the origin to the destinations.
Flow bundle
TFlowFuzzy
COM: TFlowMatrix
OD pair filter
Blocking back
Generate demand matrix from paths

Furthermore, they are regarded for the following operations:

Paths list output


Draw paths
COM (Paths interface)
Route export
Subnetwork generation
ANM export
Demand matrix calibration
Optimization of the signal timing coordination

The following operations cannot be applied to LUCE paths:

5.13.7

Conversion into PrT paths or vice versa


Changes to the course or the volume of a path
Route import

Start from an initial assignment


Like other PrT assignment methods, also LUCE can use an existing assignment result as initial
solution to save computation time during the next run if supply and demand had changed only
slightly. Prerequisite: The existing assignment needs to be a LUCE result and the path
information (bushes) must have been stored. Different PrT assignments cannot start with a
LUCE result as initial solution and vice versa.

PTV AG

343

Chapter 5: User model PrT

5.13.8

Optimizing the proportionality in the route distribution


According to Wardrop's equilibrium condition the link volumes are determined explicitly, but the
path volumes are not necessarily. This is clearly illustrated in the example in illustration 100.

Illustration 100: Example for the proportionality with balanced link volumes

The zones 1 and 2 are connected to node A, the zones 3 and 4 are connected to node B. A
and B are connected by the two links x and y, which have the same VDF. Demand is 500 trips
each from 1 to 3 and from 1 to 4. The image shows the resulting link volumes in the balanced
state. But the link volumes can result from the various route volumes overlaying on the links.
Three of them are listed in the table:
Volume

Variant 1

Variant 2

Variant 3

1-x-3

200

500

250

1-y-3

300

250

1-x-4

300

250

1-y-4

200

500

250

Table 112: Variants of route volumes for the link volumes in illustration 100

With regard to the impedance balance, all variants are equivalent, though variant 3 has the
advantage that the route distribution at node A is proportional for the relations to the zones 3
and 4. Since the links x and y have the same impedance one cannot assume that at node A
road users on their way to the destination x will not distribute to the links in the same way as
those heading to destination y.
Due to the separate handling of the OD pairs, the path-based equilibrium procedure could
generate any of the indefinite number of path volume variants arbitrarily, whereas LUCE
always charges the paths proportionally as shown in variant 3. But this advantage is based on
the fact, that LUCE simultaneously balances all path volumes to an origin zone. Identical turn
proportions can therefore be generated within an origin zone only, they are not reached for the
routes of various origin zones.
This is illustrated by the extended example in illustration 101, now with 500 trips each between
the zones 2 and 3, and 2 and 4. Again, the image shows balanced link volumes.

344

PTV AG

Chapter 5.13: Linear User Cost Equilibrium (LUCE)

Illustration 101: Extended example for the proportionality with balanced link volumes

Even though the route distributions to the paths within an origin zone show consistent shares,
this does not apply to the paths of different origin zones. Again various volume variants can be
generated:
Volume

Variant 1

Variant 2

Variant 3
250

1-x-3

200

500

1-y-3

300

250

1-x-4

200

500

250

1-y-4

300

250

2-x-3

300

250

2-y-3

200

500

250

2-x-4

300

250

2-y-4

200

500

250

Table 113: Variants of route volumes for the link volumes in illustration 101

For the same reason as above, variant 3 is the preferable variant, since there is no need for
unequal loading of the routes. However, this balancing procedure cannot be performed in a
purely origin-based way. LUCE provides the option to harmonize the path volumes over all
origin zones subsequently to the determination of meshes of the same impedance (compare
mesh A-B in the example) which is based on the paths that were calculated during the actual
assignment. This is always the case, since in an isolated view the mesh is in a balanced state;
thus, volumes can be shifted between the path alternatives from different origin zones without
any changes to the link volumes or impedances. Thus, the equilibrium state can be retained.
Since mesh finding and route choice optimization are time-consuming this procedure is
provided as an option which can additionally be activated in the LUCE procedure parameters.
For the reliable detection of balanced meshes the assignment should have finished with a gap
of 10-6 or better. In this case, the optimization of the route distribution will additionally take
another 20% - 50% of the assignment run time.
The optimization of the route distribution is highly recommended if route volumes shall be
analyzed or used in further computations. This applies to the following operations:

PTV AG

Matrix estimation though TFlowFuzzy


Flow bundles (especially flow matrix analyses)
Blocking back model

345

Chapter 5: User model PrT

But if primarily link-related assignment results are required (volumes, travel times), then
optimization is not required, since this would not improve the given results.

5.14

Equilibrium_Lohse
The Equilibrium_Lohse procedure was developed by professor Lohse and is described in
Schnabel (1997). This procedure models the learning process of road users using the network.
Starting with an "all or nothing assignment", drivers consecutively include information gained
during their last journey for the next route search. Several shortest routes are searched in an
iterative process whereby for the route search the impedance is deduced from the impedance
of the current volume and the previously estimated impedance. To do this, the total traffic flow
is assigned to the shortest routes found so far for every iteration step.
During the first iteration step only the network impedances in the free network are taken into
account (like 100 % best-route assignment).
The calculation of the impedance in every further iteration step is carried out using the current
mean impedances calculated so far and the impedances resulting from the current volume, i.e.
every iteration step n is based on the impedances calculated at n-1.
The assignment of the demand matrix to the network corresponds to how many times the route
was found ("kept in mind" by Visum).
The procedure only terminates when the estimated times underlying the route choice and the
travel times resulting from these routes coincide to a sufficient degree; there is a high
probability that this stable state of the traffic network corresponds to the route choice behavior
of drivers.
To estimate the travel time for each link of the following iteration step n+1, the estimated travel
time for n is added to the difference between the calculated actual travel time of n (calculated
from the VD functions) and the estimated travel time of n. This difference is then multiplied by
the value DELTA (0.15...0.5) which results in an attenuated sine wave.
The termination condition arises from the requirement that the estimated travel times for
iteration steps n and n-1, and the calculated actual travel time of iteration step n, sufficiently
correspond to each other. This is defined by the precision threshold EPSILON.

5.14.1

Example of the Equilibrium_Lohse procedure


The Equilibrium_Lohse procedure is demonstrated below with a calculation example. The
table 114 shows the parameter settings of the Equilibrium_Lohse and the impedance for links
and routes in the unloaded network. The table 115, table 116 and table 117 then show three
iterations of the calculation process.
LinkNo
1

Type

Length [m]
20

5,000

v0 [km/h]

Capacity [car units]


100

R0* [min]

1,200

03:00

20

5,000

100

1,200

03:00

20

5,000

100

1,200

03:00

20

5,000

100

1,200

03:00

Table 114: Impedance in unloaded network, input parameters of Equilibrium_Lohse method

346

PTV AG

Chapter 5.14: Equilibrium_Lohse

LinkNo

Type

Length [m]

v0 [km/h]

Capacity [car units]

R0* [min]

20

5,000

100

1,200

03:00

20

5,000

100

1,200

03:00

30

16,000

80

800

12:00

30

5,000

80

800

03:45

10

40

10,000

60

500

10.00

11

40

5,000

60

500

05:00

Table 114: Impedance in unloaded network, input parameters of Equilibrium_Lohse method


Route

Links

Length [m]

1+8+9

26,000

R0* [min]
0:18:45

1+2+3+5+6+7

30,000

0:18:00

10+11+5+6+7

30,000

0:24:00

Input parameters:

BPR function with a = 1, b = 2, c = 1


LowerLimit = 0.15
UpperLimit = 0.5
V1 = 2.5

V2 = 4
V3 = 0.002

2.5

f ( TT ) = ----------------------------------------

1+e

4 0.002 TT

LinkNo Volume 1 [car units] R1 [min]

TT1

f(TT1)

Delta 1

R1* [min]

2.78

0.0452

0.4796

07:00 a.m.

2,000

11:20 AM

2,000

11:20

2.78

0.0452

0.4796

07:00

2,000

11:20

2.78

0.0452

0.4796

07:00

2,000

11:20

2.78

0.0452

0.4796

07:00

2,000

11:20

2.78

0.0452

0.4796

07:00

2,000

11:20

2.78

0.0452

0.4796

07:00

12:00

0.00

0.0450

0.5000

12:00

03:45

0.00

0.0450

0.5000

03:45

10

10.00

0.00

0.0450

0.5000

10:00

11

05:00

0.00

0.0450

0.5000

05:00

Route

Volume 1

R1

R1*

0:27:05

0:22:45

Table 115: Example of Equilibrium_Lohse: 1st iteration step

PTV AG

347

Chapter 5: User model PrT

Route

Volume 1

R1

R1*

2,000

1:08:00

0:41:59

0:49:00

0:35:59

Table 115: Example of Equilibrium_Lohse: 1st iteration step

LinkNo

Volume 2 [car units] R2 [min]

TT2

f(TT2)

Delta 2

R2* [min]

2,000

11:20

0.62

0.0450

0.4925

09:08

1,000

05:05

0.27

0.0450

0.4962

06:03

1,000

05:05

0.27

0.0450

0.4962

06:03

1,000

05:05

0.27

0.0450

0.4962

06:03

1,000

05:05

0.27

0.0450

0.4962

06:03

1,000

05:05

0.27

0.0450

0.4962

06:03

1,000

30:45

1.56

0.0451

0.4855

21:06

1,000

09:37

1.56

0.0451

0.4855

06:36

10

10.00

0.00

0.0450

0.5000

10.00

11

05:00

0.00

0.0450

0.5000

05:00

Route

Volume 2

R2

R2*

1,000

0:51:42

0:36:50

1,000

0:36:45

0:39:22

0:30:15

0:33:08

Table 116: Example of Equilibrium_Lohse: 2nd iteration step

348

LinkNo

Volume 3 [car units] R3 [min]

TT3

f(TT3)

Delta 3

R3* [min]

1,333

0.27

0.0450

0.4963

07:56

06:42

667

03:56

0.35

0.0450

0.4953

05:00

667

03:56

0.35

0.0450

0.4953

05:00

1,333

06:42

0.11

0.0450

0.4984

06:22

1,333

06:42

0.11

0.0450

0.4984

06:22

1333

6:42 AM a.m. 0.11

0.0450

0.4984

06:22

667

20:20

0.0450

0.4994

20:43

0.04

667

06:21

0.04

0.0450

0.4994

06:28

10

667

27:47

1.78

0.0451

0.4842

18:37

11

667

13:53

1.78

0.0451

0.4842

09:18

PTV AG

Chapter 5.14: Equilibrium_Lohse

Route

Volume 3

R3

R3*

667

0:33:23

0:35:07

667

0:34:40

0:37:03

667

1:01:47

0:47:02

Table 117: Example of Equilibrium_Lohse: 3rd iteration step

The table 114, table 115, table 116 and table 117 illustrate the first three iteration steps of the
Equilibrium_Lohse procedure for the example network.

Iteration step 1, n = 1

Volume 1
The volume of the first iteration step results from an "all or nothing" assignment onto the
lowest impedance route in the unloaded network. For impedance R0*, this is route 2 loaded
with 2,000 car trips.

Current impedance R1
The current impedance R1 of every link results from the BPR capacity function (a =1, b = 2,
c= 1). For link 1, for example, the following can be calculated:
R1 (link 1) = 3 min x (1+(2,000/1,200)) = 11 min 20s

Estimated impedance R1*


The estimated impedance R1* of every link consists of the current impedance R1 and the
estimated impedance R0* of the last iteration step. It results from the learning factor . To
determine R1* for link 1, the following calculations are necessary:

R0* = 3 min = 180 s

R1 = 11 min 20s = 680 s

TT1 = |R1 - R0*| /R0* = |680 s - 180 s| / 180 s = 2.78

V1
2.5
- = -------------------------------------------f ( TT 1 ) = ------------------------------------= 0.0452
V 2 V 3 TT 1
4 0.002 2.78
1+e
1+e
1 = Bottom +

Top Bottom
0,5 0,15
= 0.15 +
= 0.4796
(
)
f
TT
(1 + TT1 ) 1
(1 + 2.78)0.0452

R1* = R0* + 1 (R1 - R0*) = 180 s + 0.4796 (680 s - 180 s) = 420 s

Iteration step 2, n = 2

Volume 2
The lowest impedance route for R1* is route 1. Now two routes exist, route 1 and 2. Each
route is loaded with 1/n, i.e. the demand, so that each route is used by 1,000 cars.

Current impedance R2
The current impedance R2 of every link increases on newly loaded links 8 and 9, and it
decreases on links 2, 3, 5, 6 and 7.

PTV AG

349

Chapter 5: User model PrT

Estimated impedance R2*


The estimated impedance R2* of every link consists of the current impedance R2 and the
estimated impedance R1* of the last iteration step.

Iteration step 3, n = 3

Volume 3
The lowest impedance route for R2* is route 3. 2,000 car trips are now equally distributed
across routes 1, 2 and 3.

Current impedance R3
The current impedance R3 again results from the current volume 3 via the VD function.

Estimated impedance R3*


The estimated impedance R3* of every link consists of the current impedance R3 and the
estimated impedance R2* of the last iteration step.

Iteration step 4, n = 4
The concluding route search based on R3* determines route 1 as the shortest route. Thus, the
following route volumes result:

5.14.2

Volume route 1 = 2/4 2,000 = 1,000 trips


Volume route 2 = 1/4 2,000 = 500 trips
Volume route 3 = 1/4 2,000 = 500 trips

Input and output attributes of the Equilibrium_Lohse procedure


To execute the Equilibrium_Lohse procedure, certain entries must be made. After calculation,
the results are available in the output attributes and can be displayed in the list view (see User
Manual, Chpt. 12.1, page 1369) or in the network editor (see User Manual, Chpt. 12.2,
page 1400). The table 118 gives an overview of which input attributes have to be maintained.
The table 119 lists the output attributes which store the results of the procedure.

350

PTV AG

Chapter 5.14: Equilibrium_Lohse

Table 118: Input attributes of the Equilibrium_Lohse procedure

The abbreviations represent the following:

PTV AG

x1

Toll PrTSys has to be inserted manually in the impedance function

(X)

Can be used optionally

(*)

Apart from the parameters which are directly set in the assignment procedure

351

Chapter 5: User model PrT

Table 119: Output attributes of the Equilibrium_Lohse procedure

352

PTV AG

Chapter 5.14: Equilibrium_Lohse

5.14.3

Procedure of the Equilibrium_Lohse assignment


The succeeding steps in the Equilibrium_Lohse procedure are illustrated by illustration 102.

Input

Upper and lower threshold of delta: upper and lower


parameters of the f(TT) function: V1, V2, V 3
Termination conditions: max. number iterations N;
E1, E2, E3 for determining the max. deviation E of impedance

n = 0, R n=0* = Impedance in unloaded network

n=n+1

Route
search

Route
volumes

Determination of shortest route rn for all OD pairs based on


impedance Rn-1*
If route rn is new route r: Count r = 1
If route rn already exists as router : Countr = Countr +1

Determine volumes for all routes of any relation ij:


Route volume qr = (Fij / n) Countr

Rn = impedance at current volume n

TTn = Rn R *n 1 R *n 1
Impedance
determination

f (TTn ) = V1 (1 + e V2 V3 TTn )
n = lower +

upper lower
(1 + TTn ) f (TTn )

R*n = R*n 1 + n (Rn Rn*1 )

Query

no

n = N or for every link applies:

Rn R

*
n 1

< E = E1 Rn 1

E2 / E3

yes
End
Illustration 102: Procedure of the Equilibrium_Lohse assignment

PTV AG

353

Chapter 5: User model PrT

5.14.4

Evaluation of the Equilibrium_Lohse procedure


Under the condition that a sufficient number of iteration steps (N > 40) are carried out and that
the procedure is not terminated due to the condition n = N, the Equilibrium_Lohse method
produces realistic, stable results. Even in networks with low saturation, the distribution of
volumes onto alternative routes is good. The greater number of iteration steps necessary for a
good solution usually requires more route searches than the equilibrium assignment. This
results in longer computing times.

5.15

Assignment with ICA


Compared to other procedures, using volume-delay functions by lane which are permanently
re-calibrated by means of ICA causes a significantly improved convergence behavior, since
the lane geometry and interdependencies between the individual turns via a node are regarded
in detail.

5.15.1

Fundamental principle
In Visum, any variant of the equilibrium assignment uses volume-delay functions for links and
turns to model the impedance that increases with increasing volumes. In urban network
models, the Turn VDFs are of particular importance, since the nodes affect the network
performance to a much greater extent than links do. The mathematical formulation of the
assignment problem assumes, that the impedance which is calculated by the VDFs depends
only on the volume and the capacity of the individual network object (link, turn). Volume delay
functions with this property are called separable VDFs. In reality, this holds approximately for
links, but it does not apply to turns via nodes. Typical counter-examples are the permitted turns
at signalized nodes or turns from minor approaches at two-way nodes. In these cases, the
impedance does not only depend on the volume of the turn itself, but also from the volumes of
the conflicting flows, i.e. the volumes of other turns via this node. Thus, the associated volumedelay functions can no longer be separable. This is a problem for the mathematical solution of
the assignment problem, since existence and uniqueness of the equilibrium solution require
separable volume-delay functions.
Two requirements can be derived from this analysis:

354

Realistic impedance modeling for nodes premises that nodes are modeled in detail in a way
that conflicts between turns can be identified correctly. Transferred to Visum this means,
that for these nodes the geometry and control have to be modeled in the junction editor.
Subsequently, precise impedances and capacities of the turns can be calculated using the
Intersection Capacity Analysis (ICA).
For lack of separability, the values calculated by means of ICA may not directly be used to
replace the volume-delay functions in the assignment procedure, since the convergence
would get lost then.

PTV AG

Chapter 5.15: Assignment with ICA

Illustration 103: ICA-based impedance calculation

Visum by-passes the separability problem by an approximation approach. The procedure


consists of an interaction between an equilibrium assignment procedure (using conventional
VDFs) and node impedance calculation (ICA). First, equilibrium assignment is used to
calculate the turn volumes. After the assignment, blocking back calculation ensures that the
volumes used for ICA are realistic, i.e. do not lie in the overloaded range. ICA is then used to
calculate the turn capacities and wait times for volumes. Subsequently, the volume of each turn
is varied, while volumes of the other turns at the same node are retained in order to calculate
wait times for other volume conditions. The wait times calculated for the individual turns are
interpolated to estimate a CR function. These turn-specific VD functions are used in the next
equilibrium assignment. They model the dependence of the impedance on only the turn
volume while the conflicting flows are regarded as if being constant. From the assignment's
point of view, the effect of conflicting flows is "frozen" thereby until (after more equilibrium
iterations) these flows are also updated in the next ICA calculation. In this way, the volumedelay functions are stabilized for some iterations in each case to favor convergence. As
blocking back calculation is performed after the assignment, additional wait times might occur
due to a traffic jams. They, however, must be considered for route search and choice of the
subsequent equilibrium assignment. This is achieved by manipulating the assigned link VD
function in the range exceeding effective capacity, so that the wait time of blocking back
calculation is depicted in the VD function. In contrast to link capacity, effective capacity
accounts for the actual flow through rate of a link, which might lie below capacity due to
spillback congestion. Adaptation of the link VD function is only done for links that, similar to
modeled nodes, typically lie in the center of the examined area. The feedback loop between
assignment and ICA ends, as soon as the impedances calculated by the VD function or ICA do
no longer significantly differ. For all other links and connectors, the assignment with ICA uses
regular VD functions, where applicable. Their parameters do not depend on the individual
network object, however, for links they depend on the link type only.

PTV AG

355

Chapter 5: User model PrT

5.15.2

Evaluation of the Assignment with ICA


The assignment with ICA is a static and accounts for detailed node impedances.
Specific advantage: Normally ICA cannot be applied properly while an assignment is running,
since the VD functions are not separable. In the approach described, turn VD functions are
made "roughly separable" by "freezing" the conflicting flows in equilibrium assignment.
Normally, convergence is reached in this way. Simultaneously, the Turn VDFs are
continuously adjusted to the wait times and capacities calculated by ICA. The HCM 2000
method (HCM 2000 or HCM 2010) used by ICA is one of the most highly approved analysis
methods for node performance calculations and considers the lane distribution and conflicting
turns in detail.
The disadvantage is the significantly higher time and effort for modeling and calibration, since
nodes whose impedances are to be calculated by ICA have to be modeled in detail. If you do
not want to model all nodes in detail in your network model you should make sure that for the
other nodes volume-delay functions are used which provide impedance data in a comparable
scale. The route choice will be distorted if mixed impedances are produced by ICA turns and
non-ICA turns systematically: Then, for example, only routes are chosen that do not traverse
ICA nodes.
Using the iterative approach, assignment with ICA requires more computation time than a
conventional equilibrium assignment. Additional spillback and ICA calculations are required.
Adaptation of the turn VD functions after subordinate equilibrium assignment mostly leads to a
setback in convergence, which must be offset through recalibration.
As in other assignment procedures, you can use existing assignment results as a starting point
for an assignment with ICA in order to save time. The assignment results used must stem from
an assignment with ICA. Only then is it guaranteed that the attributes used at turns and links
have been calculated. This procedure can be used to calculate scenarios in which the network
basis and demand data do not radically change. The parameters previously estimated thus
form a good basis for recalibration.
For the assignment with ICA, one of the subordinate assignment procedures you can use is
LUCE equilibrium assignment. You might prefer this procedure for assignment with ICA for the
following reasons:

356

With the Use current assignment result as initial solution option set by default. the
assignment times required for subordinate LUCE assignment are short.
Stable route distribution, especially with option Optimization of the proportionality of
route volumes at meshes.
Calculation of the blocking back model, using so-called bushes, is considerably faster than
conventional calculation methods.
Due to the stable routes, also the blocking back result is more stable and thus convergence
can be reached sooner.

PTV AG

Chapter 5.15: Assignment with ICA

5.15.3

Input and output attributes of the assignment with ICA


Prior to the calculation of an assignment with ICA, certain attributes of network objects and also
procedure parameters have to be set. After calculation, the results are available in the output
attributes and can be displayed in the list view (see User Manual, Chpt. 12.1, page 1369) or in
the network editor (see User Manual, Chpt. 12.2, page 1400). The table 120 gives an overview
of which input attributes have to be maintained. It is important that for those nodes whose turn
impedances you want to calculate in detail using ICA, you select the Node impedance
calculation (ICA) option for the Method for impedance at node attribute and set the Use
preset method for impedance at node attribute to TRUE. The table 121 lists the most
important output attributes of the procedure for turns.
The following prerequisites are required for the assignment with ICA:

PTV AG

Prior to the assignment with ICA calculation, the geometry and control need to be modeled
correctly for the nodes the ICA impedance calculation has been activated for. To check
whether the calculation can be performed correctly for all nodes, from the Calculate menu,
choose >Network check and check the Viability for ICA option.
For turns, the design volume PrT needs to be a volume-representing attribute (Volume PrT
or Volume PrT with base). Enter the settings via menu Calculate > General procedure
settings > navigator entry PrT settings > Node impedances. For the design volume PrT,
only factor 1.0 is permitted. This is due to the fact, that the calibration of the VDFs by turn
would fail otherwise. The VD function used for turns is based on the hourly capacities
output by ICA. This means that you can only perform assignment with ICA for assignment
periods of 1h. As a result, hourly values for link and turn capacities must be defined.

357

Chapter 5: User model PrT

Table 120: Input attributes of the assignment with ICA

358

PTV AG

Chapter 5.15: Assignment with ICA

The abbreviations represent the following:


x1

Toll-PrTSys has to be inserted manually in the impedance function to have an effect

x2

Takes effect in the framework of the blocking back model

(x)

Can be used optionally

For the output of results, the following options are provided:


There are different output variants: Primarily, the assignment with ICA fills the usual attributes
of the various network object types (link, turn, etc.) with the calculated volumes and
impedances. In addition to the common volume and travel time attributes, there are the
following output attributes at (main) turns and links that are only filled through assignment with
ICA:
Attribute

Meaning

Is ICA turn in ICA assignment

Indicates whether the ICA-Turn function is to be used for this turn in the
assignment with ICA.

Final capacity for assignment


with ICA

Last capacity used during assignment with ICA. The Capacity PrTV
attribute is not used for turns at (main) nodes calculated with ICA.

Final t0 for assignment with


ICA

t0 that was recently used with ICA assignment. The t0 PrT attribute is
not used for (main) turns at nodes calculated with ICA.

Final smoothed volume for


assignment with ICA

Smoothed volume resulting from recent iteration.

tCur-PrTSys for assignment


with ICA

tCur of the turn-specific VD function, including the final VD function


parameters. In contrast, the attribute tCur-PrTSys stores the result
calculated in the recent ICA calculation.

Final A for assignment with


ICA

Final VD function parameter A for the turn-specific VDF

Final B for assignment with


ICA

Final VD function parameter B for the turn-specific VDF

Final capacity for assignment


with ICA

corresponds to smoothed capacity of (main) turns calculated with ICA

Deterred upstream volume in


assignment with ICA

Deterred volume refers to the part of the volume that, according to


blocking back calculation, is held back at bottlenecks upstream from the
(main) turn and so does not reach it.

Table 121: Additionally calculated turn/main turn attributes for assignment with ICA
Attribute

Meaning

Effective capacity for


assignment with ICA

On uncongested links, effective capacity corresponds to link capacity or


the Capacity PrT attribute. On congested links, it corresponds to the
traffic volume exiting the link.

Deterred upstream volume in


assignment with ICA

Deterred upstream volume refers to the part of the volume that,


according to blocking back calculation, is held back at bottlenecks
upstream from the (main) turn and so does not reach it.

Table 122: Additionally calculated link attributes for assignment with ICA

PTV AG

359

Chapter 5: User model PrT

Furthermore, numerous diagnostic outputs are provided which can be used for convergence
check. If the procedure converges either slowly or not at all, the outputs provide useful
information, e.g. which turns show significant differences when calculated with ICA impedance
calculation or the VD function.

As long as the procedure is running, you can watch the process in the "Goodness of PrT
assignment with ICA" list.
*.csv files are created to which the program saves turn attribute data after each iteration.
These files are helpful when you want to compare the development of attribute values of
individual turns during the course of assignment with ICA.
Some result attributes of the assignment with ICA are saved to user-defined attributes, if
required. This data can be used for the comparison of the convergence reached in different
runs of the assignment with ICA. To do so, first copy the values of the user-defined
attributes, before they are overwritten during the next calculation.
Optionally, an Excel report is created which contains the results of the recent ICA
calculation. From the report it is to be seen, which volumes were used for the calculation
and which capacities resulted from that. For nodes of the all-way stop type, the v/c value is
output the same way as for nodes of the two-way stop type.

The precise times, when attribute data is stored in an iteration is described with the procedure
(see "Procedure of the Assignment with ICA" on page 360).

5.15.4

Procedure of the Assignment with ICA


The assignment with ICA is based on the iterative solution for the user optimum with volumedelay functions for all network objects. The distinctive feature is that the parameters of the turn
VD functions can be set by turn ("turn-specific) and might change during the calculation due to
the adjustment of the ICA calculation results, as described with the fundamental principle (see
"Fundamental principle" on page 354).

360

If the assignment with ICA is not based on existing assignment results, the parameters
used in the VD function for turns and links are first initialized. For turns, the input values are
used that you have specified in the Procedure parameters window (Input tab). Depending
on the control type used, additional signal times and geometric data are considered. The
parameters initialized for turn capacities, t0, and the VD functions A and B are used to
perform the first subordinate assignment. The link attribute Effective capacity in
assignment with ICA is initialized with the Capacity PrT value. If your assignment with
ICA is based on existing assignment results, the parameters are available from the last
assignment with ICA and initialization is skipped.
First the subordinate assignment procedure is performed. Choose one of the following
assignment procedures: Equilibrium assignment, Equilibrium_Lohse or Equilibrium
assignment (LUCE). For nodes, for which ICA calculation has been activated, use turnspecific VD functions. In this case, no ICA calculations are carried out during the
subordinate assignment procedure.
The turn-specific VD functions used and the adaptation of link VD functions are described
in separate paragraphs (illustration 104).

PTV AG

Chapter 5.15: Assignment with ICA

After completion of the subordinate assignment procedure, the blocking back model is
applied. For calculation of the blocking back model, the turn capacities at nodes calculated
with ICA are taken into account.. Optionally, you may additionally use the capacities
defined in the link capacity model. The link impedance results obtained through blocking
back model calculation are adjusted in order to account for the additional wait times caused
by traffic jams on the links.
Notes: By applying the blocking back model, only phase 1 is calculated.
The blocking back model is not applied while the subordinate assignment procedure is
performed.
During finalization of the ICA assignment, the global parameters of the blocking back
model (see User Manual, Chpt. 5.5.2, page 1008) are adapted to the procedure
parameters of ICA assignment, i.e. settings that differ are first ignored during ICA
assignment and then overwritten.

PTV AG

Prior to the ICA calculation, the current values are determined for volume and impedance
and also the parameters of the VDFs are recorded (according to the settings: in attribute
files, as user-defined attributes and in the Goodness of PrT assignment with ICA list).
Then, the turn volumes calculated in the recent iteration and in the current iteration are
smoothed, i.e. the weighted mean is calculated.
Using ICA, the program calculates turn impedances and capacities. For this ICA
calculation, the design volume used is the smoothed turn volume (including the basic
volume, depending on the design volume set).
Calculation of the new, turn-specific VD functions is performed in two steps and separately
for each turn. In the first step, the parameters of the VD function are determined through
interpolation of three sampling points. One sampling point is given by the smoothed turn
volumes and the respective impedance (see previous step). To determine two additional
sampling points, reduce or increase the volume of the turn currently being processed, while
maintaining the other turn volumes passing via the node. The impedance of the current turn
is then recalculated with ICA. Since the VD function to be interpolated possesses three free
parameters (t0, A, B), it is clearly defined by the three sampling points. In the second step,
these parameters and also the capacity are smoothed by means of the values resulting
from the previous iteration. In the procedure parameters, a minimum capacity per turn can
be set. If the smoothing result is below the minimum capacity, the minimum capacity will be
used instead. The convergence check is performed after the determination of the new
VDFs. If the convergence constraints are satisfied, the parameters of the VDF will be reset
to the value of the recent iteration. This means the VD functions are in accordance with the
subordinate assignment last performed. In the flow diagram, qTn represents the volume of
turn T in iteration n.
If the convergence test is failed, the attributes Deterred upstream volume in assignment
with ICA, for links and turns, and Effective capacity in assignment with ICA, for links,
are updated. These values are required for application of the VD function during the next
subordinate assignment (or for an assignment based on existing assignment results).

361

Chapter 5: User model PrT

362

PTV AG

Chapter 5.15: Assignment with ICA

Illustration 104: Procedure of the assignment with ICA

5.15.5

VD functions in assignments with ICA


The following sections describe the turns VD function and adjustment of the links VD function
during assignment with ICA

5.15.5.1 Used turn VDF


The turns VD function is used for assignment with ICA of all opened turns whose nodes include
a Node impedance calculation (ICA).
B

max ( 0, q q-
t 0 + A ----------------------------------
cap
t cur ( q, cap, t 0, A, B, q ) =
t + A
else
0

if q q cap

Thereby
tcur

PTV AG

Turn attribute corresponds to tCur of the turn-specific VD function including the VD function
parameters. Attribute tCur_PrTSys for assignment with ICA contains the value calculated
at the end of the assignment with ICA.

363

Chapter 5: User model PrT

A and B

Attributes of the respective turns.


The attributes Final A for assignment with ICA and Final B for assignment with ICA
include the values calculated at the end of the assignment with ICA.

q
t0

Turn volume in subordinate assignment (without spillback congestion)

cap

Turn attribute that corresponds to smoothed capacity in the assignment with ICA.
Attribute Final capacity for assignment with ICA contains the value calculated at the end
of the assignment with ICA.

Turn attribute calculated as the difference between demand volume and volume. Deterred
volume refers to the part of the volume that, according to blocking back calculation, is held
back at bottlenecks upstream from the turn and so does not reach it.
Attribute Deterred volume upstream in assignment with ICA contains the value
calculated at the end of the assignment with ICA.

Turn attribute
Attribute Final t0 for assignment with ICA contains the value calculated at the end of the
assignment with ICA.

During the assignment, the factors A and B are updated with each ICA impedance calculation
per turn. You can find the values of the last iteration in the turn attributes Final A for
assignment with ICA and Final B for assignment with ICA. The following data are also
saved to turn attributes: t0 values (Final t0 for assignment with ICA), the capacity (Final
capacity for assignment with ICA), and the difference between demand volume and current
volume (Deterred volume upstream in assignment with ICA).

5.15.5.2 Adapting the link VD functions used


Generally, link VD functions are conventionally assigned during the assignment with ICA, so
you can define link VD functions based on the link type. For links with traffic jams according to
blocking back calculation, the VD functions you defined are adjusted according to the formula,
i. e. your VD functions are used to calculate volumes up to effective capacity and are then cut
off. For volumes exceeding effective capacity, the congestion wait time is calculated instead
(second term of "else" case).
vdf base ( max ( 0, q q ) )
if q q effcap

t cur ( q, cap, effcap, q ) =


T
else
vdf base ( effcap ) + ---------------- ( q effcap q )
effcap

Thereby

364

tcur

Link run time in loaded network

vdfbase

VD function defined (depends on link type)

q
cap
effcap

Link volume in subordinate assignment (without spillback congestion)


Link capacity
Link attribute calculated in each iteration after spillback calculation
Attribute Effective capacity in assignment with ICA contains the value calculated at the
end of the assignment with ICA.
The effective capacity corresponds to the link capacity on uncongested links. On congested
links, effective capacity is given by the minimum of capacity and link volume.

PTV AG

Chapter 5.16: Stochastic assignment

Link attribute that represents the difference between demand volume and volume plus
queue length. Deterred volume refers to the part of the volume that, according to blocking
back calculation, is held back upstream and so does not reach the link.
Attribute Deterred volume upstream in assignment with ICAcontains the value
calculated at the end of the assignment with ICA.

T = 1,800, i.e. T corresponds to half the assignment period [in sec]

By adapting the link VD function, you ensure that the additional impedance caused by spillback
congestion is accounted for in subordinate assignment, i.e. for route search and route choice.

5.16

Stochastic assignment
Stochastic assignment procedures assume that traffic participants in principle select the best
route, but evaluate the individual routes differently due to incomplete and different information.
In addition, in a stochastic PrT assignment the demand is distributed (see "Distribution models
in the assignment" on page 308) to the found routes as for a PuT assignment using a
distribution model (e.g. Logit, Kirchhoff, Box-Cox, Lohse or Lohse with variable beta).
In order to take the spatial similarities of the routes into account during the distribution, a
similarity measure is determined from overlapping routes (analogous to independence during
timetable-based PuT assignment) it is called the Commonality Factor (C-Logit) or the
independence of each route (according to Ben Akiva) is determined.
This results in the following sequence:
1. Route search for all traffic cells for current impedance.
2. Commonality Factor or independence calculated from overlapping of all routes of an origin/
destination pair.
3. Distribution of demand to the routes of each OD pair, taking the Commonality Factor or
independence into account.
4. Repeat from step 3 until demand for all OD pairs is in equilibrium.
5. Repeat steps 1 4 until no new routes are found or until the change in the link volumes
between two iteration steps is very small.
During the route search, the number of possible routes can be increased in that it is not just the
shortest route that is found, but a number of alternatives are found using a multiple best path
search and a variation in the link impedances.

5.16.1

Evaluation of the stochastic assignment


Compared with the equilibrium assignment, there are more routes loaded even in a poorly
loaded network in the case of the stochastic assignment, because a (small) part of the demand
is also assigned to suboptimal routes due to the distribution model. In all cases, this property
is closer to reality than the strict application of Wardrops first principle.

PTV AG

365

Chapter 5: User model PrT

5.16.2

Input and output attributes of the stochastic assignment


To execute the stochastic assignment, certain entries have to be made. The table 123 gives an
overview of which input attributes have to be maintained. After calculation, the results are
available in the output attributes and can be displayed in the list view (see User Manual, Chpt.
12.1, page 1369) or in the network editor (see User Manual, Chpt. 12.2, page 1400). The
table 124 lists the output attributes which store the results of the procedure.

Table 123: Input attributes for the stochastic assignment

366

PTV AG

Chapter 5.16: Stochastic assignment

The abbreviations represent the following:


x1

Toll PrTSys has to be inserted manually in the impedance function

(x)

Can be used optionally

(*)

Apart from the parameters which are directly set in the assignment procedure

Table 124: Output attributes for the stochastic assignment

5.16.3

Procedure of the stochastic assignment


The procedure is broken down into an external and an internal iteration (illustration 105).

PTV AG

The external (global) iteration with iterator n is used for the route search. This loop is
repeated until either n = N or until no new shortest routes are found.
The internal iteration with iterator m is used to assign the volume to the routes. This loop is
repeated until either m = M or until the deviations of the impedances on the network
elements and the deviation of the volumes on the routes between two iteration steps is very
small.

367

Chapter 5: User model PrT

Start of
external
iterartion
Search
impedance

Counter for
external
iteration

Route search

Termination
external
iteration
R oute
preselection

Independence

368

n =0

C alculate impedance R in the unloaded network for all


network elements.

n= n + 1

C alculate one route per OD pair using a shortest path


search with R n.
Generate other routes by varying R n based on a standard
distribution curve with pre-defined variance.
Option: Insert route only, if the detour test is successful,
i.e. the new route is not a trivial version of an existing
route.

N umber of new shortest routes > 0

no
stop

ja
Delete all routes with R > a R* min + b and
t0 > c t 0,min + d

C alculate independence factor (commonality factor) that


takes into account the relative similarity of the routes or
calculate the independence (Ben Akiva)

PTV AG

Chapter 5.16: Stochastic assignment

Start of internal
iteration
Initialisation of
choice
impedance

m =0

Set impedance R or R* of all network objects to


impedance in the unloaded network.

Counter for
internal
iteration

m= m +1

Calculate R * of all routes as a total R * for all traversed


network objects.
Correct impedance using impedance factor.

Choice
impedance

Assignment of demand across the routes in accordance


with Logit, Box-Cox, Kirchhoff, Lohse or Lohse with
variable beta results in route volumes q rm*

Route choice

q rm =

Route volume

Update search
impedance

q r (m1) ( m 1) + q rm '
m

Calculate R * for all network objects from the volumes that


result from the route choice.
The search impedance is an estimated R * value that is
calculated as in the Equilibrium_Lohse procedure:

*
*
Rnew
= Ro*ld + Rnew Rold

m = max. number of internal iterations or


is valid for the impedance of all network elements, and

Termination
criterion for
internal
iteration

Rm* Rm* 1 min( E1 max( R*m, R*m1 ) + E 2 , E3 )

no

is valid for the volume of all routes

q rm q r (m1) min( E4 max(q rm , q r( m1) ) + E5 , E6 )

Termination of
external
iteration

ja
n = max. number of external iteration
stop

no

yes

Illustration 105: Procedure of the stochastic assignment

The alternative route search by stochastic variation of the impedances is closely related to
other procedures used to determine k-shortest paths and shares their common drawback that
often new routes are found that differ insignificantly from previous routes. Such routes are not
desirable as they hardly change the volume situation in the network and only increase the route
quantity, which leads to extended computing time and higher memory requirements. For this
reason a detour test is offered as part of the stochastic assignment that discards a route r2 if a
route r1 already exists that matchesr2, with the exception of a subsection, and if this subsection

PTV AG

369

Chapter 5: User model PrT

in r2 is significantly longer than in r1. More precisely, r2 is discarded in favor of r1 if the following
applies (illustration 106).

r1 = AT1B

r2 = AT2B

Length(T2) > Factor Length(T1)

Illustration 106: Discarding routes

The route sections A and B can be empty if the subsection is at the start or the end of the
routes.

5.16.4

Similarity of routes and commonality factor


In the case of the stochastic assignment, alternative routes are generated - based on another
assignment as initial solution - for an OD pair by varying the impedances of the network objects
based on a distribution, in order to model the incomplete information supplied to the road-users
and their individual differences in terms of perception and preferences. In this way, it is
possible to calculate in one step not only the shortest route in terms of impedance, but also
alternative routes with higher impedances. After completion of the route search, depending on
the route impedance based on an assignment model (Logit, Box-Cox, Kirchhoff, Lohse or
Lohse with variable beta), the demand is distributed across the alternatives. The similarity of
the routes is to be taken into account during the distribution process. The problem of similarity
is illustrated with the example below (illustration 107):
Whereas the independence of the routes is given in cases 1 and 2, there is a dependence of
routes 1 and 3 in case 3, since there is some degree of overlap. This overlapping must be
taken into consideration in the route choice.

370

PTV AG

Chapter 5.16: Stochastic assignment

Case 1

Portion

Route 1

expected

Logit

Route 1

50%

50%

Route 2

50%

50%

Route 2

Impedance R1 = R2

Case 2

Portion

Route 1

expected

Logit

Route 1

33%

33%

Route 2

33%

33%

Route 3

33%

33%

Route 3

Impedance R1 = R2 = R3

Case 3

Portion

Route 2
Route 1

expected

Logit

Route 1

approx.
28%

33%

Route 2

approx.
44%

33%

Route 3

approx.
28%

33%

Route 3

Impedance R1 = R2 = R3

Route 2

Illustration 107: Example for similarity of routes

The C-Logit approach proposed by CASCETTA is a suitable way of overcoming this problem.
To do this, a so-called commonality factor C is introduced to measure the overlapping of the
two routes r and s as follows:

PTV AG

371

Chapter 5: User model PrT

t 0 rs
l rs
C rs = --------------------- or C rs = --------------t0 r t0 s
lr ls

with
Crs

Similarity of the routes r and s (Commonality factor)

t0rs

Time t0 of the common sections of the routes r and s

t0r

Time t0 of route r

lrs

Length l of the common sections of the routes r and s

lr

Length l of route r

Thus, Crs equals 1, if the two routes are identical, and will be 0, if the two routes do not overlap.
The commonality factor Crs is determined for all route combinations. Then, the correction factor
CFr of a route r compared to any other route s is defined as follows:
1 - = --------------------------------1
CF r = --------------- Crs 1 + Crs
rs

The correction factor of a route r is 1 if the commonality factors Crs for all routes s have the
value 0, i.e. the route has no overlap with another route. In any other case it is below 1. The
correction factor CFr is then regarded in the Logit model as follows:
Vr

e CFr
P = ------------------------------------------N

s = 1 ( e

Vs

CF s )

In the case of Box-Cox, Kirchhoff, Lohse or Lohse with variable beta, its inclusion is also
carried out in the same way.
Alternatively, the correction factor CFr can be determined using a simpler approach according
to Ben Akiva. It is then defined as:
CF r =

t0 a

- ---------
a P -----t 0 r N ija

or
CF r =

la

a P ---lr- --------N ija

with

372

t0a

Time t0 of link a

t0r

Time t0 of route r

la

Length l of link a

lr

Length l of route r

Nija

Number of routes of the OD pair ij that lead across link a

PTV AG

Chapter 5.16: Stochastic assignment

5.16.5

Example for the stochastic assignment


The table 125 shows the main key input data for the sample network. If the following
parameters are chosen for the search, then in a single external iteration, all 3 conceivable
routes will be found:

Number of search iterations = 5

= 8 R0.5
Compared to the "objective" impedances (resulting from impedance definitions and VDFs),
the impedances of the network objects are changed for alternative shortest path searches.
They are drawn randomly from a normal distribution which has the objective impedance R
as mean value and whose standard deviation is given as a function of R.

LinkNo

Type

v0 [km/h]

Length [m]

Capacity [car units]

R0* [min]

R0* [s]

20

100

5,000

1,200

03:00

180

20

100

5,000

1,200

03:00

180

20

100

5,000

1,200

03:00

180

20

100

5,000

1,200

03:00

180

20

100

5,000

1,200

03:00

180

20

100

5,000

1,200

03:00

180

30

80

16,000

800

12:00

720

30

80

5,000

800

03:45

225

10

40

60

10,000

500

10:00

600

11

40

60

5,000

500

05:00

300

Route

Links

Length [m]

R0* [min]

R0* [s]

1+8+9

26,000

0:18:45

1,125

1+2+3+5+6+7

30,000

0:18:00

1,080

10+11+5+6+7

30,000

0:24:00

1,440

Input parameters
BPR function with a = 1, b = 2, c = 1
Bottom = 0.5, Top = 0.5 = 0.5
Assignment with Logit, = 0.001
Table 125: Impedance in the unloaded network, input parameters for stochastic assignment

After completing the search, the correction factor for the independence of each route is
determined according to Cascetta. It is based on the similarity of the individual route pairs with
reference to time t0 or to the length. The table 126 shows the commonality factors C. From this,
the correction factor CFr of route r is calculated.

Route 1
1 - = ----------------------------------------1
CF 1 = ---------------= 0.8596
+
1.0
0.16
+ 0.0
C
1j
j

PTV AG

373

Chapter 5: User model PrT

Route 2
1 - = -------------------------------------------1
- = 0.6264
CF 2 = ---------------+
0.16
1.0
+ 0.43
C
2
j

Route 3
1 - = ----------------------------------------1
CF 3 = ---------------= 0.6978
+
0.0
0.43
+ 1.0
C3 j
j

Route pair

t0ij

t0i

t0j

Cij

1,1

1,125

1,125

1,125

1.00

1.2

180

1,125

1,080

0.16

1.3

1,125

1,440

0.00

2,1

180

1,080

1,125

0.16

2.2

1,080

1,080

1,080

1.00

2,3

540

1,080

1.440

0.43

3,1

1,440

1,125

0.00

3,2

540

1,440

1,080

0.43

3.3

1,440

1,440

1,440

1.00

Table 126: Calculation of the commonality factor C for all route pairs

The share by route is calculated from the correction factor according to Cascetta and from the
impedance Rmin0 in the unloaded network.
For Route 1, the portion is calculated using the Logit model as follows:
-0.0011125

0.8596 e
P 1 = ---------------------------------------------------------------------------------------------------------------------------------------------------------------= 0.425
-0.0011125
-0.0011080
-0.0011440
0.8596 e
+ 0.6264 e
+ 0.6978 e
In the same way, the portions showed in the table 127 result for Routes 2 and 3. The volume
of each route qr1 in the first iteration step results from the product of portion P and demand F.
For Route 1, the calculation is as follows: 0.425 2000 = 849.4 PCU. From the route volumes,
the link volumes and thus the network impedances can then be calculated (illustration 108).
This results in the impedances R1 of the routes. These interim results can be verified in Visum
if the maximum number of internal iterations are set to M = 1 in the assignment parameters.
Route

Rmin0

exp(Rmin0)E

Portion P

qr1

R1

0.8596

1,125

0.279079049

0.425

849.4

2,470

0.6264

1,080

0.212737561

0.324

647.5

1,961

0.6978

1,440

0.165335421

0.252

503.2

2,848

0.657152032

1.000

2,000.0

Total

Table 127: Volumes in the first internal iteration step m = 1

374

PTV AG

Chapter 5.16: Stochastic assignment

A Village

X City

Illustration 108: Volumes and link run times after the first internal iteration step m=1

For the route choice in the second iteration step, an estimated impedance Rmin1 is calculated.
Since = 0.5, this impedance results from the formation of the mean value of Rmin0 and R1. On
the basis of Rmin1, as in the first iteration step, the assignment is then made for the 3 routes.
For each route, the interim result is qr2. To smooth the volumes between two iteration steps,
the MSA method (Method of Successive Averages) is used.
q r ( m 1 ) ( m 1 ) + q rm'
q rm = ---------------------------------------------------------m

For m = 2, this results in the following for the volume of Route 1:


( 2 1 ) + 788.8q r 2 = 849.4
--------------------------------------------------------2

This route volume then leads to the link volumes and impedances of the second iteration step
(table 128). The iterations are repeated until the termination criteria are met.
Route

Rmin1

exp(R)E

Portion P

qr2

qr2

R2

0.8596

1797.6

0.142432

0.3944

788.8

819.1

2,405.2

0.6264

1,520.7

0.136919

0.3791

758.3

702.9

2,016.0

0.6978

2,144.0

0.081775

0.2264

452.9

478.0

2,785.6

Total

0.361126

2,000

Table 128: Volumes in the second internal iteration step m = 2

PTV AG

375

Chapter 5: User model PrT

5.17

TRIBUT
Taking road toll into consideration, a constant value of time is set in conventional procedures,
which in principle can be used to convert the costs (toll) into time and the conventional
monocriterial assignment procedures are directly applicable.
Compared to the conventional approach, TRIBUT uses a concurrent distributed time value.
Accordingly, TRIBUT calculates in the route search as well as in the route choice with two
separate criteria, namely with time and costs (bicriterion).
This method has been used for many years in France, for the evaluation of privately financed
freeways with toll management. Compared to the conventional approach, this approach is a
more realistic price elasticity when using toll roads.
Road tolls are transport system-specific and can either be defined for a link or a link sequence.
Using link sequences allows modeling of non-linear toll systems.
Road toll modeling is an add-on which basically can be used with any equilibrium assignment
procedure. Visum provides two extensions of this kind: TRIBUT-Equilibrium (as extension to
the "Equilibrium" method) and TRIBUT-Learning procedure (as extension to the
"Equilibrium_Lohse" method).

5.17.1

Input and output attributes of the TRIBUT procedure


To execute a TRIBUT procedure, certain entries must be made. The table 129 gives an
overview of which input attributes have to be maintained. After calculation, the results are
available in the output attributes and can be displayed in the list view (see User Manual, Chpt.
12.1, page 1369) or in the network editor (see User Manual, Chpt. 12.2, page 1400). The
table 130 lists the output attributes which store the results of the procedure.

376

PTV AG

Chapter 5.17: TRIBUT

Table 129: Input attributes for TRIBUT

The abbreviations represent the following:


0

PTV AG

Generally possible, however not recommended

377

Chapter 5: User model PrT

Table 130: Output attributes for TRIBUT

5.17.2

Basics of the assignment with toll consideration


The decisive feature of an assignment procedure is the impedance definition for route
evaluation and route choice. With all toll-regarding assignment procedures, the impedance Rr
of a route r consists of travel time tr and monetary costs cr:
R r = t r + c r VT

Here, VT is the value of time in [/h], for example. Though this equation applies to all tollregarding assignment procedures, the TRIBUT procedure differs from other procedures in two
properties:

Monetary route costs can be calculated in different ways.


The value of time VT is no constant value per demand segment, but VT is modeled as
stochastic parameter that varies according to a particular probability distribution.

Link toll
In the simplest case, the route's monetary costs result from summing up the toll amounts by
link along the route.
The following applies:

378

tL = t(VolL)

Travel time on a link L as a function of the volume

VolL

Volume of link L

CL

Toll value for using link L

VT

Value of time in [/h], for example

PTV AG

Chapter 5.17: TRIBUT

This toll type applies to the HGV toll in Germany, for example: On parts of the network
(highways), heavy goods vehicles have to pay a toll amount which is precisely proportional to
the covered distance. Thus to each link of the highway link type the product from the link length
x constant km cost multiplication can be allocated as toll amount. For any other link and for any
other transport system, the toll amount = 0. The total of these amounts summed up along a
route represents the cost resulting from the distance traveled on highway links for the transport
system HGV.
For link toll, no toll system has to be defined. It is not necessary either to include the link
attribute Toll-PrTSys in the impedance definition, since TRIBUT regards this amount
automatically.
Note: The TRIBUT-Equilibrium assignment always regards the link-specific toll values. The
TRIBUT-Learning procedure only regards the link-specific toll values of links which do not
belong to any toll system.

Area toll
Especially toll systems for inner city areas often use a different type. For the area toll, a
geographically coherent section of the network is stated as toll area. A distance-independent
fixed amount is charged, if a section of a route runs through the toll zone.
c
R r = t r + ------r- =
VT

c
------t
+
L r L VT
0

if a ( L r ) lies in the toll area


else

Illustration 109: Example for area toll: The London Congestion Charging Zone

PTV AG

379

Chapter 5: User model PrT

At first view, the monetary costs of a route do not depend on the individual links being
traversed, but on the route course as a whole in this case. Basically this is right, however,
TRIBUT - like any other assignment procedure - is based on shortest path searches via links
and requires the impedances by link therefore. That is why TRIBUT puts the area toll down to
the link toll case. For that, define the toll area first by creating a network object 'toll system' of
the area toll type and then allocating the toll area's number to all links which are located in the
area as value for the attribute Toll system number. The toll system additionally stores the
fixed toll amount for each transport system. For the clear definition of the figure described
below, all connector nodes of a zone need to be located either within the toll area or outside of
it.
On this basis, TRIBUT defines the toll amounts for links, turns, and connectors as follows:
cL = 0 for all links L
cC = 0 for all connectors C
c
c T = T --- for all turns T, with T = 1, if turn T leads from a link inside the toll area to a link
2

outside or vice versa, i.e. if the toll area border is crossed. Otherwise, T = 0.
c
c X = X --- for all transitions X from connectors to links, where X = 1, if the transition X leads
2

to a link in the toll area or originates from there. Otherwise, X = 0.


The illustration 110 illustrates the principle:
Zone 2

Zone 1

Link outside
of toll area
Link inside
of toll area
Turn with toll
Connector
with toll
Connector
without toll

Illustration 110: Reducing the area toll to the link toll case
(For clarity reasons, turns without toll are not displayed)

Summing up the toll amounts along a route results in an amount null for routes that do not
touch the toll area at all. Any other route (origin traffic, destination traffic, through traffic, internal
traffic of the toll area) is charged with the toll amount of c, since they traverse exactly two
network objects with toll amount = c/2 each.
In a Visum model, you can define multiple toll systems of the area toll type. Then, the
definitions for turn and connector cost are applied to each toll system with the associated fixed
toll amount. For turns between two toll areas the two toll amounts are charged.
Please note the two characteristics. For routes, that cross the border of the toll area multiple
times the toll amount is charged multiple times. This might not correspond to reality, however
it cannot be avoided for the required reduction to additive toll amounts per network object.
Furthermore, the internal traffic within the toll area can be excluded from toll calculations in

380

PTV AG

Chapter 5.17: TRIBUT

reality. For the TRIBUT route choice it is no problem that these flows are nevertheless charged
with toll amounts, since the toll comparably refers to all route alternatives and thus this additive
constant value does not modify the equilibrium solution. But when calculating a skim matrix of
the impedance for future use in a demand model for example, you need to perform an
additional matrix operation after skim matrix calculation to subtract the toll amount from the
internal traffic OD pairs data.
Note: Only the TRIBUT-Learning procedure takes the area toll into consideration.
For links that belong to a toll system the link attribute Toll-PrTSys is not regarded.

Matrix toll
Another type of toll models is often applied to arterial highways. In this case we have a
physically cohesive subnetwork with a limited number of connections (entries and exits) to the
remaining network (illustration 111).

Illustration 111: Toll station at highway exit

Toll amounts are not defined as the sum of toll amounts by link, but arbitrarily as fee by pair
(entry, exit). Using such a fee matrix, the operator has more flexibility since the tol