PTV Visum-Fundamentals

VISUM 11.
52 Fundamentals
VISUM 11.52 Fundamentals
Copyright
25.2.11 PTV AG, Karlsruhe
All brand or product names in this document are trademarks or registered trademarks of the
corresponding companies or organizations. All rights reserved.
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.
This manual may not be reproduced , stored in a retrieval system, or transmitted, in any form,
or by any means, electronic, mechanical, photocopying, recording, or otherwise, edited or
translated, except for the buyer's personal use as permitted under the terms of the copyright,
without the prior written permission of PTV AG.
Warranty restriction
The content accuracy of this manual 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
info.vision@ptv.de
www.ptvag.com
www.ptv-vision.de
Last amended 25. Februar 2011 EN-US nF
PTV AG I
Structure
Structure
1 Program basics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Network model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Demand model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4 Impact models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
5 User Model PrT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
6 User Model PuT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
7 Operator model PuT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
8 Environmental impact model and HBEFA . . . . . . . . . . . . . . . . . . . . . . 613
9 Economic assessment according to EWS . . . . . . . . . . . . . . . . . . . . . . 625
10 GIS functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
11 Interactive analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
12 Tabular and graphic display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
List of illustrations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
List of tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755
II PTV AG
Structure
PTV AG III
Contents
Contents
1 Program basics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Network model the transport supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Demand model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Impact models methods to calculate the impact of traffic . . . . . . . . . . . . . . . . . . 6
1.4 Evaluation of results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Comparing and transferring networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5.1 Comparing version files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.2 Network merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.3 Model transfer files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 Network model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1 Network objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.1 Transport systems, modes and demand segments . . . . . . . . . . . . . . . . . . . . . . 22
2.1.2 Nodes and turns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1.3 Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1.4 Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.1.5 OD pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.1.6 Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.1.7 Main nodes and main turns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.1.8 Main zones and main OD pairs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.1.9 Territories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.1.10 Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.1.11 Stop hierarchy: Stops, stop areas, stop points . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.1.12 PuT operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.1.13 PuT vehicles: vehicle units and vehicle combinations. . . . . . . . . . . . . . . . . . . . . 45
2.1.14 The line hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.1.15 System routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.1.16 Points of Interest (POI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.1.17 Count locations and detectors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.1.18 Toll systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
2.1.19 GIS objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
2.1.20 Screenlines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
2.1.21 Junction modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.1.22 Network check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.2 Spatial and temporal correlations in VISUM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.2.1 Calendar and valid days . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.2.2 Time reference of the demand (time series) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2.2.3 Time reference of volumes: analysis time intervals and projection. . . . . . . . . . . 75
2.2.4 Temporal and spatial differentiation of calculation results. . . . . . . . . . . . . . . . . . 79
2.2.5 Adjustment of the capacities to the demand values . . . . . . . . . . . . . . . . . . . . . . 80
2.3 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
IV PTV AG
Contents
2.3.1 Direct attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
2.3.2 Indirect attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
2.3.3 User-defined attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
2.3.4 Time-varying attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
2.4 Subnetwork generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
2.5 The surface data model in VISUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
2.5.1 Tables in the surface model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
2.5.2 Multi-part surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
3 Demand model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
3.1 Demand objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103
3.1.1 Matrices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.1.2 Demand segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.1.3 Time series. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.1.4 Demand model structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.1.5 Population groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.1.6 Activities, Activity Pairs, Activity Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
3.1.7 Demand strata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
3.2 Demand modeling procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109
3.2.1 Standard Four-Stage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
3.2.2 EVA Model for Passenger Demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
3.2.3 Activity chain based model (VISEM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
3.2.4 Estimate gravitation parameters (KALIBRI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
3.2.5 Gravity model calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
3.2.6 Modal Split (standardized assessment) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
3.2.7 Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
3.3 Displaying and Editing Matrices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .170
3.3.1 Displaying matrices in tabular form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
3.3.2 Matrix values displayed as histogram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
3.3.3 Transpose, reflect upper or lower triangle, apply mean value . . . . . . . . . . . . . . 172
3.3.4 Copy, paste and apply diagonal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
3.3.5 Round. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
3.3.6 Form reciprocal, raise to power, take logarithm, exponential function . . . . . . . . 173
3.3.7 Maximum or minimum formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
3.3.8 Make symmetrical: Mean value upper / lower triangle . . . . . . . . . . . . . . . . . . . . 173
3.3.9 Calculate the combination of matrices and vectors . . . . . . . . . . . . . . . . . . . . . . 173
3.3.10 Projection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
3.3.11 Converting zone and main zone matrix into each other . . . . . . . . . . . . . . . . . . . 175
3.3.12 Extending matrices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
3.3.13 Aggregating matrix objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
3.3.14 Splitting (extending) matrix objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
3.4 Matrix correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179
3.4.1 Updating demand matrix with TFlowFuzzy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
3.4.2 Projecting PrT Path Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
3.4.3 Calibrating a PrT matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
4 Impact models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
PTV AG V
Contents
4.1 The types of impact models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
4.1.1 The user model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
4.1.2 The operator model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
4.1.3 The environmental impact model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
4.2 Impedance functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
4.3 Paths in PrT and PuT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
4.4 Skims / indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
4.4.1 Skim matrices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
4.4.2 Global indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
5 User Model PrT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
5.1 Overview of the PrT assignment procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
5.2 Example network for the PrT assignment procedures . . . . . . . . . . . . . . . . . . . . 197
5.3 PrT Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
5.4 Impedance and VD functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
5.4.1 Impedance of a PrT route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
5.4.2 Predefined VD functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
5.4.3 Example of the calculation of the link impedance . . . . . . . . . . . . . . . . . . . . . . . 209
5.4.4 User-defined VD functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
5.5 Impedances at node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
5.5.1 Impedance of turns from Turns VD function . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
5.5.2 Impedance of turns from Nodes VD function . . . . . . . . . . . . . . . . . . . . . . . . . . 212
5.5.3 Intersection Capacity Analysis according to the Highway Capacity Manual
(ICA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
5.5.4 Signal timing optimization.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
5.6 PrT skims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
5.7 Distribution of the traffic demand to PrT connectors. . . . . . . . . . . . . . . . . . . . . . 272
5.8 Blocking back model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
5.8.1 General notes on the blocking back model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
5.8.2 Procedure of the blocking back model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
5.9 Convergence criteria of the assignment quality . . . . . . . . . . . . . . . . . . . . . . . . . 288
5.10 Distribution models in the assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
5.10.1 The Kirchhoff model in the assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
5.10.2 The Logit model in the assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
5.10.3 The Box-Cox model in the assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
5.10.4 The Lohse model in the assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
5.10.5 Lohse model with variable beta in the assignment . . . . . . . . . . . . . . . . . . . . . . 293
5.10.6 Comparison of the distribution models for the assignment . . . . . . . . . . . . . . . . 295
5.11 Incremental assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
5.11.1 Example of the incremental assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
5.11.2 Procedure of the incremental assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
5.11.3 Input and output attributes of the incremental assignment . . . . . . . . . . . . . . . . 299
5.11.4 Evaluation of the incremental assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
5.12 Equilibrium assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
VI PTV AG
Contents
5.12.1 Evaluation of the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
5.12.2 Introductive example for the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . 303
5.12.3 Input and output attributes of the equilibrium assignment . . . . . . . . . . . . . . . . . 305
5.12.4 Procedure of the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
5.12.5 Calculation example for the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . 311
5.13 Linear User Cost Equilibrium (LUCE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .312
5.13.1 Mathematical formulation and theoretical framework. . . . . . . . . . . . . . . . . . . . . 313
5.13.2 Local user equilibrium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
5.13.3 Descent direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
5.13.4 Assignment algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
5.13.5 Input and output attributes of the equilibrium assignment (LUCE) . . . . . . . . . . . 323
5.13.6 Persistent storage of bushes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
5.14 Equilibrium_Lohse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .324
5.14.1 Example of the Equilibrium_Lohse procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 325
5.14.2 Input and output attributes of the Equilibrium_Lohse procedure . . . . . . . . . . . . 328
5.14.3 Procedure of the Equilibrium_Lohse assignment . . . . . . . . . . . . . . . . . . . . . . . . 330
5.14.4 Evaluation of the Equilibrium_Lohse procedure. . . . . . . . . . . . . . . . . . . . . . . . . 331
5.15 Assignment with ICA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .332
5.15.1 Fundamental principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
5.15.2 Evaluation of the procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
5.15.3 Input and output attributes of the assignment with ICA . . . . . . . . . . . . . . . . . . . 334
5.15.4 Description of the procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
5.15.5 Used turn VDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
5.16 Stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .342
5.16.1 Evaluation of the stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
5.16.2 Input and output attributes of the stochastic assignment . . . . . . . . . . . . . . . . . . 342
5.16.3 Procedure of the stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
5.16.4 Similarity of routes and commonality factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
5.16.5 Example for the stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
5.17 TRIBUT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .353
5.17.1 Input and output attributes of the TRIBUT procedure . . . . . . . . . . . . . . . . . . . . 353
5.17.2 Basics of the assignment with toll consideration . . . . . . . . . . . . . . . . . . . . . . . . 355
5.17.3 LogN distribution of the random variable VT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
5.17.4 Route search - efficient frontier as exclusive criterion . . . . . . . . . . . . . . . . . . . . 363
5.17.5 Route split . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
5.17.6 Route balancing in the equilibrium iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
5.17.7 Route distribution in the iteration of the TRIBUT Equilibrium_Lohse . . . . . . . . . 365
5.17.8 List outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
5.18 Dynamic User Equilibrium (DUE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .367
5.18.1 Fields of application of the Dynamic User Equilibrium procedure . . . . . . . . . . . 367
5.18.2 Overview of the dynamic equilibrium assignment model . . . . . . . . . . . . . . . . . . 367
5.18.3 Mathematical framework of the Dynamic User Equilibrium . . . . . . . . . . . . . . . . 370
5.18.4 Network performance model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
5.18.5 Assignment of the network demand (network loading) . . . . . . . . . . . . . . . . . . . 384
5.18.6 The overall model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
5.18.7 Example of the Dynamic user equilibrium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
PTV AG VII
Contents
5.18.8 Input and output attributes of the dynamic user equilibrium (DUE). . . . . . . . . . 390
5.19 Dynamic stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
5.19.1 Evaluation of the Dynamic stochastic assignment . . . . . . . . . . . . . . . . . . . . . . 399
5.19.2 Input and output attributes of the dynamic stochastic assignment . . . . . . . . . . 399
5.19.3 Procedure of the dynamic stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . 400
5.20 NCHRP 255 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
5.21 Assignment analysis PrT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
6 User Model PuT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
6.1 Overview of PuT assignment procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
6.2 Example network for the PuT assignment procedures. . . . . . . . . . . . . . . . . . . . 409
6.3 PuT paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
6.4 PuT skims. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
6.4.1 PuT skim categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
6.4.2 Perceived journey time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
6.4.3 Fares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
6.4.4 Temporal utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
6.5 PuT impedance functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
6.6 Distribution of the travel demand to PuT connectors . . . . . . . . . . . . . . . . . . . . . 426
6.7 Allocation of skims with reference to lines/links . . . . . . . . . . . . . . . . . . . . . . . . . 427
6.8 Transport system-based assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
6.8.1 Evaluation of the transport system-based assignment . . . . . . . . . . . . . . . . . . . 429
6.8.2 Example for the transport system-based assignment . . . . . . . . . . . . . . . . . . . . 429
6.8.3 Steps of the transport system-based assignment . . . . . . . . . . . . . . . . . . . . . . . 430
6.9 Headway-based assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
6.9.1 Evaluation of the headway-based assignment . . . . . . . . . . . . . . . . . . . . . . . . . 431
6.9.2 Headway calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
6.9.3 Generalized costs as impedance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
6.9.4 Choice models for boarding decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
6.9.5 The complete choice model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
6.9.6 The search in general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
6.9.7 Example for the transport system-based assignment . . . . . . . . . . . . . . . . . . . . 446
6.9.8 Coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
6.10 Timetable-based assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
6.10.1 Evaluation of the timetable-based assignment . . . . . . . . . . . . . . . . . . . . . . . . . 452
6.10.2 Connection search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
6.10.3 Connection preselection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
6.10.4 Perceived journey time PJT of a connection. . . . . . . . . . . . . . . . . . . . . . . . . . . 455
6.10.5 Connection Choice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
6.10.6 Handling of public transport systems of the PuT-Aux type . . . . . . . . . . . . . . . . 465
6.10.7 Opening of the timetable-based assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . 466
6.11 Assignment analysis PuT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
6.12 PuT Passenger surveys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
6.12.1 Basic data of a passenger trip. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
VIII PTV AG
Contents
6.12.2 Passenger onboard survey: Basic approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
6.12.3 Read survey data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
6.12.4 Plausibilization of survey data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
6.12.5 Assignment of survey data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
7 Operator model PuT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
7.1 Application areas and scope of operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . .489
7.1.1 Calculation of indicators on different aggregation levels . . . . . . . . . . . . . . . . . . 490
7.1.2 Introductory examples for PuT indicators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
7.2 Network objects in the operator model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .498
7.3 Typical work flow in the PuT operator model . . . . . . . . . . . . . . . . . . . . . . . . . . .499
7.4 Line blocking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .500
7.4.1 Introduction into the line blocking procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
7.4.2 Application example for line blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
7.4.3 Data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
7.4.4 Line blocking description without vehicle interchange . . . . . . . . . . . . . . . . . . . . 528
7.4.5 Line blocking description with vehicle interchange. . . . . . . . . . . . . . . . . . . . . . . 538
7.4.6 Displaying and editing blocks in the timetable editor . . . . . . . . . . . . . . . . . . . . . 542
7.4.7 Vehicle requirement and line blocking indicators . . . . . . . . . . . . . . . . . . . . . . . . 543
7.4.8 Description of the PuT interlining matrix procedure . . . . . . . . . . . . . . . . . . . . . . 545
7.5 PuT fare model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .546
7.5.1 Short overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
7.5.2 Ticket types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549
7.5.3 Fare systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
7.5.4 Fare calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
7.5.5 Application of fares. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
7.6 PuT Operating Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .568
7.6.1 Demonstration example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
7.6.2 Indicators for line route and timetable evaluation. . . . . . . . . . . . . . . . . . . . . . . . 572
7.6.3 Measurement of the transport supply. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
7.6.4 Measurement of the network performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
7.6.5 Calculation of operating costs and fare gains (revenues) . . . . . . . . . . . . . . . . . 584
7.6.6 Calculation of the operating costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
7.6.7 Calculation of the fare revenues (revenue calculation) . . . . . . . . . . . . . . . . . . . 594
7.6.8 Basic calculation principles for indicators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
8 Environmental impact model and HBEFA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
8.1 Noise volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .613
8.1.1 Noise-Emis-Rls90 procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
8.1.2 The Noise-Emis-Nordic procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
8.1.3 Link attributes for noise calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
8.2 Air pollution emissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .616
8.2.1 Pollution-Emis procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
8.2.2 Pollutant-Emis link attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
8.3 Emission calculation according to HBEFA 3.1 . . . . . . . . . . . . . . . . . . . . . . . . . .618
8.3.1 Fundamental principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
PTV AG IX
Contents
8.3.2 Basics of the HBEFA calculation in VISUM. . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
9 Economic assessment according to EWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
9.1 EWS basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
9.2 EWS link attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
9.3 EWS Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
9.4 EWS Cost-benefit analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
10 GIS functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
10.1 Connection to the Personal Geo Database and GIS objects . . . . . . . . . . . . . . . 633
10.2 Shape files as a GIS interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
10.2.1 Importing shape files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
10.2.2 Exporting shape files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
10.3 Intersect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
10.4 Coordinate systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646
10.5 Processing the network display with graphic objects . . . . . . . . . . . . . . . . . . . . . 648
10.5.1 Texts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
10.5.2 Legend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
10.5.3 Backgrounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
10.5.4 Polygons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
10.6 GPS tracking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
11 Interactive analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
11.1 Flow bundles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
11.1.1 Flow bundle definition by selecting network objects . . . . . . . . . . . . . . . . . . . . . 657
11.1.2 Flow bundle definition through selection of traffic types . . . . . . . . . . . . . . . . . . 660
11.1.3 Combination of flow bundle criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
11.1.4 Flow bundles with alternative routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665
11.2 Isochrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
11.2.1 PrT isochrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
11.2.2 PuT isochrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671
11.2.3 Combination of PrT and PuT isochrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
11.3 Shortest path search. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
12 Tabular and graphic display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
12.1 Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
12.1.1 Specific network object lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
12.1.2 Matrix list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684
12.1.3 Evaluation lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684
12.2 Bars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
12.3 Categorized display with attribute values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
12.4 Labeling with tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
12.5 Labeling with diagrams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
12.6 Turn volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
X PTV AG
Contents
12.7 Desire lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .696
12.8 Stop catchment areas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .698
12.9 Lane allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .700
12.10 2D display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .702
12.11 Timetable network graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .704
12.12 Column charts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .706
12.13 Evaluations in the timetable editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .707
Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
List of illustrations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
List of tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755
1 PTV AG
1 Program basics
VISUM is a software system that integrates all individual and public transport types in a single
model. It is supplemented with the microscopic traffic simulation system VISSIM. Together the
programs make up the ptv vision system. Most basic data supplied with transport information
and planning systems can be managed consistently with VISUM and updated using a network
editor. Unlike simple GIS systems, VISUM allows complex relationships within single or
several transport systems to be retained. In this way, an appropriate transport model can be
created.
The transport model normally consists of a demand model, a network model based on VISUM
and various impact models (illustration 1):
The demand model contains the travel demand data. 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. In VISUM the Standard-4-Step, EVA and VISEM
models are integrated. This is how you can create travel demand matrices in the program
(see "Demand model" on page 103).
The network model describes the relevant supply data of a transport system. It consists of
traffic zones, nodes, public transport stops, links and public transport lines with their
timetable. Transport supply data can be visualized with VISUM and edited interactively with
different methods.
The impact model takes its input data from the demand model and the impact model.
VISUM provides different impact models to analyze and evaluate the comprehensive
transport system. A user model simulates the travel behavior of public transport
passengers and car drivers (see "User Model PuT" on page 407 and "User Model PrT" on
page 195). 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, vehicle kilometers, number of vehicles or operating costs
(see "Operator model PuT" on page 489). Derived from the demand data, the estimates
allow line related revenues for a line costing calculation. An environmental impact model
offers several methods to assess the impacts of motorized transport on the environment
(see "Environmental impact model and HBEFA" on page 613).
VISUM displays the calculated results in graphic and tabular form and allows graphical
analyses of results. In this way, for example, routes and connections per OD pair, flow
bundles, isochrones, and node flows can be displayed and analyzed. Indicators such as
journey time, number of transfers, service frequency, and many more are computed as
skim matrices.
Different versions can be compared by a version comparison or the network merge
process. Via model transfer files model modifications can be exchanged between the
models.
2 PTV AG
Chapter 1: Program basics
Illustration 1: VISUM network model and impact model
A transportation model, like all models 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 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 trafficzones. The most important network object types in VISUM are described here.
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.
Network model
contains supply data:
Transport systems,
traffic zones,
nodes and stop points,
links,
PuT lines with line routes and time
profiles.
Transport model Transport model
Demand model
contains demand data:
Origin, destination,
number of trips by
demand segment.
Temporal
distribution of travel
demand.
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 (calculated attributes of network objects and routes)
Indicator matrices (journey time, service frequency, ...)
Graphical analysis (flow bundles, isochrones, ...)
Plots
3 PTV AG
Chapter 1.2: Demand model
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 distance 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 illustrate 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 zone.
Every network object is described by its attributes. Attributes can be subdivided as follows:
Input attributes such as link lengths or link numbers
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 tabular and graphically, and are available as filters. 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 Demand model
Travel demand develops when a sequence of activities (living - working - shopping - living)
cannot be carried out at the same location and thus requires a journey.
The travel demand is saved in a matrix, where all zones contained in a traffic model are in
columns and rows.
A matrix element of the PrT has the unit car trips, matrix element of the PuT has the unit
OD trips (do not mistake with the trip of a PuT line!). It contains the number of travel
demand from a traffic zone i to a traffic zone j.
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).
4 PTV AG
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 (four-stage model) can be calculated,
besides traffic assignment (choice and volume of the route to get from origin zone to
destination zone) the other three stages 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 indicators (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 indicators. 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 indicators. These indicators
can again be used as inputs for trip distribution or mode choice of a new demand calculation.
The Go to the operation operation allows iterating the calculations until a convergence
criterion concerning link volumes or matrix values is fulfilled.
VISUM contains three alternative calculation models for the demand modeling.
The Standard-4-Step Model is based on North American practice for aggregated demand
models (see "Standard Four-Stage Model" on page 110).
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
5 PTV AG
Chapter 1.2: Demand model
well as by its particular method of balancing the differences between origin and destination
traffic (see "EVA Model for Passenger Demand" on page 115).
When calculating demand matrices, the VISEM 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 (VISEM)" on page 144).
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 links 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 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, Traffic 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.
Time series by percentage of a 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
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
6 PTV AG
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.
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 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.
Transport 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
0
5
10
15
20
25
30
35
40
7:00 8:00 7:30 9:00 8:30
%
7 PTV AG
Chapter 1.4: Evaluation of results
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.
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.
1.4 Evaluation 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 graphic
display" on page 679 and "Interactive analyses" on page 655).
Flow bundles, which filter demand segment-specific paths traversing network objects
selected by the user (nodes, links, zones, stop points, stop areas and stops)
Evaluation 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 relation 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
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
8 PTV AG
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 rows (for example link volumes in the course of the
day)
Graphic and tabular display of trips 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 file)
1.5 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 12)
Model transfer files (see "Model transfer files" on page 15)
Version comparison and network merge
To compare transport networks, the Version comparison function has been introduced from
VISUM 11.5 onwards in addition to the classical Difference network. At the same time the
difference network has been renamed as Network merge since the merging of different data
is the main feature of this function. The following table gives an overview and lists the
differences between the two functions. In most cases you will be working with the new version
comparison in future.
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
Version comparison Network merge (previously Difference network)
Normal working is possible Simply additional
evaluation attributes are created, which can be
deleted or updated, if required.
Special mode serving mere evaluation purposes,
hardly editable, not saveable
Simultaneous comparison of various variants
possible
Comparison with exactly one variant
New evaluation attributes 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 12)
Attributes and network objects to be compared can
be selected.
All attributes and network object types are
compared.
Updatable by pushing a button Not updatable
9 PTV AG
Chapter 1.5: Comparing and transferring networks
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 is used for a quick and easy addition of attribute values from other
network variants and their comparison with the values of the current network. Network objects
with the same keys are compared. Therefore, compared to the Network merge function, this
function is more suitable for networks basically including the same network objects.
Use cases for version comparison
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.

The version comparison
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 numerical attribute compared additional attributes specifying the absolute difference, the
relative deviation as well as the minimum and maximum are created.
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.
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 15).
New attribute Short name German Long name German
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
10 PTV AG
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 "Evaluation
of results" on page 7).
Illustration 3: Network of the original version
11 PTV AG
Illustration 4: Network of the version used for version comparison
Illustration 5: Network with version comparison: The volumes of both versions compared as well their
difference is displayed. Verscomp is the name of the version comparison.
Above all, you can convert the attribute values of the additionally read version easily into user-
defined attributes so that they are still available after the version comparison has been
terminated.
12 PTV AG
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 of version comparisons
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.
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 subattributes of an attribute are different in A and B, only those subattributes valid in
A are considered. Subattributes which do not exist in B have an empty attribute value.
1.5.2 Network merge

The network merge function provides for the comparison of two transport networks and the
display 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. Network 1 compared to network 2 contains one
link more, furthermore the links have different attribute values TSysSet and v0PrT.
Note: Prior to VISUM version 11.5 this function was called Difference network.
13 PTV AG
Illustration 6: Network 1 for the merge network
Illustration 7: Network 2 for the 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 networks (for example, the keys for links from 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.
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.
In no network: The object exists only in the merge network and has no attribute values.
Example: A turn between links from network 1 and one from network 2. Such objects are
14 PTV AG
created in rare cases so that the merge network is a permissible VISUM network. They
have no real equivalent and have 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 subattribute with values Net1, Net2 and Diff. Net1 and Net2 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 Diff. subattribute 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.

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
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
15 PTV AG
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.
The model transfer files constitute the basis for scenario management, which will be available
in VISUM 12.
When creating the model transfer file, you can specify which data you want to save and which
not. However, as when saving a network normally, you have to take care that the selection
made makes sense.
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.
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 editor has edited links, reads
the model transfer file and adds the new zones to his network.
16 PTV AG
17 PTV AG
2 Network model
The supply data of the transport network are described in a network model consisting of
various network objects.
Subjects
Network objects
Spatial and temporal correlations in VISUM
Attributes
Subnetwork generator
The surface data model in VISUM
2.1 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 17).
Additionally, there are network objects which are only used for modeling PuT networks (see
"PuT network objects of a transport network" on page 19) and general networks, which do not
have to have any relevance to traffic and especially no influences on procedure calculations
(see "General network objects" on page 21).
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 2: Basic network objects of a transport network
18 PTV AG
Chapter 2:Network model
Turn
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 standard Turn standards are patterns, from which an emerging turn with standard values
is allocated for their 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.
Link
Links connect nodes and thus describe the structure of the road and rail
network. A link has a particular direction, so that the opposite link represents a
separate network object and can thus have different attribute values.
Link type 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 attribute
permissible transport systems (TSysSet), Capacity PrT, velocities (v0-PrT,
vMin-PrT, vMax-PrT and vDef-PrT), Number of lanes and the link rank as
standard values.
Zone
Zones (traffic cells) describe the position of utilities 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.
Connector
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.
Main 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 aggregated 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 turn
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 zone
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.
Territory
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).
19 PTV AG
Chapter 2.1:Network objects
OD pair OD pairs (or relations) exist between all zones of the network. The values in
skim matrices and demand matrices (see "Matrices" on page 104) each refer to
one relation. Compared to the other network objects, you cannot edit relations
interactively in the network editor, but you can filter relations and display them
graphically. For each relation you can select the skim matrix values, 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 A valid day is a freely defined set of days within the used calendar. If a weekly
calendar is used, a valid day can comprise the days Monday to Sunday (for
example "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: the transport supply can be time-varying for the dynamic stochastic
assignment, DUE and the assignment procedure Metropolis. Time-varying
attributes are used (see "Time-varying attributes" on page 90). When using a
calendar, valid days can be specified for these time-varying attributes, on which
they should have an affect.
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
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.
Stop point
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 3: PuT network objects of a transport network
20 PTV AG
Line
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.
Because it is possible to create multiple time profiles per line route, you can
model so that the travel times of a tram between stop points are longer during
evening rush hours than the rest of the day. The allocation of the time profile is
carried out on trip level, so that you can assign a different time profile to each
trip.
Vehicle journey Vehicle journeys (also called service trips) are the basic objects to describe the
timetable. Each vehicle journey uses 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 service trip sections) are used to
subdivide a service trip. Different valid days and different vehicle combinations
can be defined for the vehicle journey sections of a trip. 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 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.
System route
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 trip. System routes with their path and in-vehicle-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 operator You can assign an operator to each service trip section. When working with the
operator model, you can evaluate PuT operating indicators per operator (see
"Operator model PuT" on page 489). 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 service trip section a vehicle combination. You
can assign a vehicle combination, time and distance dependent cost rates for
service trips 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 489).
21 PTV AG
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
service trips and empty trips, and cost rates for the layover in the depot and the
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. A block version can for
example, be kept in the model, where interlining is allowed and another one
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, there are the
block item types service trip, empty trip, layover time and stand in VISUM. 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.
Point of Interest (POI)
and POI category
Points of Interest are user-defined network objects with spatial reference, for
example parking facilities, pre-emption points for AVL systems or SCJ
controllers. POIs are used to display special land uses such as restaurants or
hotels, for data management as well as for reachability analyses.
Count location
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 4: General network objects
22 PTV AG
Network processing modifies the properties of the transport network which produces different
indicator values and assignment results.
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.
2.1.1 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.
Illustration 9: Connection between transport systems, modes, demand segments and demand matrices
Detector
Detectors are optional network objects provided with the count locations add-
on, they can be used for lane-based data management of counted link data.
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 object
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 Geo Database (PGD).
Screenline
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.
Table 4: General network objects
Priv.TSys1
(e.g. HGV)
Priv.TSys2
(e.g. Car)
Publ.TSys1
(e.g. Bus)
Publ.TSys2
(e.g. Tram)
Transport systems
Modes
HGV Publ.Transp
Students
Car Publ.Transport
(Bus+Tram)
Car-
private
Car-
business
HGV Park&Ride
(Car, Bus, Tram)
Publ.Transp.
Adults
P&R
Matrix Matrix Matrix Matrix Matrix Matrix
Demand
segments
Demand
matrices
23 PTV AG
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 200) 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

The four types of transport systems are different in the following ways.
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
Permissible 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 subordinate PuT transport systems without specification of a 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 possible 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.
Note: The number of modeled transport systems, modes or demand segments is not limited.
24 PTV AG
Table 5The following table provides an overview of the transport system types 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 long-
distance 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.
Demand segments can be used for differentiation among
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.
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
Run times from timetable
Transport system is not valid for transfer walks or on a connector
Bus,
Tram,
Train
PuTAux Public transport system without timetable or
PrT access system to PuT
Run times result from links
Transport system is not valid for transfer paths within a stop - just
between stops
Bus,
Taxi,
P&R access
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 5: PrT transport systems properties
25 PTV AG
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 calculation of OD trips (PrT) from car units, the occupancy rate can be specified for each
demand segment (see User Manual, Chpt. 2.10.3.2, page 180).
Assignment of demand segments
In case of all private transport assignment procedures (see "User Model PrT" on page 195),
demand segments of different 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 TSys-
specific 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 407). 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.
26 PTV AG
2.1.2.1 Nodes
Nodes determine the locations of street junctions and points in the rail network. They are
starting and terminating elements of links, where there are turning relations from one link to
another in PrT or PuT turns (see "Turns" on page 26). 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 28). Any number of nodes can be incorporated in a main
node (see "Main nodes" on page 36). 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 210). 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 Turns
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.
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 permissible/blocked transport systems
PrT capacity
PrT time penalty
The transport systems have to be specified for each turn which uses this turn. A turn
differentiates permitted and blocked transport systems.
By default, the following applies when inserting a new link:
U-turns are blocked for all transport systems at the beginning.
Other turns are open for all transport systems at first which are allowed to use the To Link.
Permitted PuT
transport systems
The turn can be used when constructing the line route.
Permitted PrT transport
systems
The turn can be used for the assignment taking the PrT capacity and the PrT
time penalty into account.
Blocked transport
systems
Prohibited turns
27 PTV AG
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 on
3: Left turn
4: U-turn
5..9: 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 patterns, 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 29). 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 6.
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 210). illustration 10 shows an example of turn
standards.
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 6: Flow hierarchy symbols
28 PTV AG
Illustration 10: 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 t
0
therefore comes from the turn time penalty.
The turn time t
Cur
in the loaded network then results from the selected VD function and the
relationship between the current traffic volume q and the capacity q
max
:
Input: Free flow turn time t
0
(turn time penalty) [s]
Input: Volume q of the turn [Car units/analysis time interval]
Input: Capacity q
max
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
(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 210).
2.1.3 Links
Links describe roads and railway tracks of the transport network. The link nodes, this means
junctions 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 permissible
transport systems of PrT and PuT (which are allowed to use the link). This means, that you can
block one of the directions for traffic and therefore model a one-way road.
* At t ent i on: t i me al ways i n seconds
* Tabl e: Tur n st andar ds
$TURNSTANDARD: I D; NODETYPE; TURNTYPE; FLOWHI ERARCHY; T0PRT; CAPPRT
1; 10; 1; - - ; 10s; 32000
2; 10; 1; - +; 10s; 32000 / / Ri ght t ur n f r ommi nor f l ow i nt o maj or f l ow
3; 10; 1; +- ; 10s; 32000 / / Ri ght t ur n f r ommaj or f l ow i nt o mi nor f l ow
4; 10; 1; ++; 0s; 32000 / / Road wi t h r i ght of way whi ch bends t o t he r i ght
5; 10; 2; - - ; 15s; 32000 / / Cr ossi ng f r ommi nor f l ow i nt o mi nor f l ow
6; 10; 2; - +; 10s; 32000
7; 10; 2; +- ; 10s; 32000
8; 10; 2; ++; 0s; 32000 / / Cr ossi ng st r ai ght f r ommaj or i nt o maj or f l ow
9; 10; 3; - - ; 20s; 32000
10; 10; 3; - +; 20s; 32000 / / Lef t t ur n f r ommi nor f l ow i nt o maj or f l ow
11; 10; 3; +- ; 15s; 32000 / / Lef t t ur n f r ommaj or f l ow i nt o mi nor f l ow
12; 10; 3; ++; 0s; 32000
t
cur
t
0
1 a
q
q
max
c
------------------

b
+

=
29 PTV AG
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 permissible transport systems on a link
Capacity PrT
Permissible PrT-speed (v0-PrT) free flow speed
Minimum speed
Number of lanes
Rank of identification of the link rating
Permissible maximum speed, vMax-TSys, of every PrT transport system
Transport system-specific road speed in PrT for toll
Transport system-specific road speed t-PuTSys, for the calculation of transport system-
specific PuT run times tPuT 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 585)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.13.2, page 212).
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 200). This is
how you can achieve, that a different mathematical coherence between the in-vehicle time for
passing a link and the traffic volume is applied on grade-separated urban roads than on at-
grade non-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 66). The major flow is taken from one of the three
criteria (see "Turn standards" on page 27) 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. Due to this cohesion, the rank of
the link type has a direct influence on the PrT assignment result. illustration 11 shows an
example of the determination of flow hierarchy and especially the major flow.
30 PTV AG
Illustration 11: Rank of the link type and its resulting major flows (yellow), flow hierarchy (red)

2.1.3.2 Permissible transport systems
The permissible 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
illustration 12 shows three examples for permissible transport systems on different types of
links.
Note: In the PuT model, the rank has no influence on the assignment result.
31 PTV AG
Illustration 12: 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, you block the
transport systems for the opposite direction.
Links which are permissible to PrT transport systems are taken into account during
private transport assignment.
Links which are permissible to PuT transport systems are taken into account during the
construction of line routes for public transport. 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.
For speed v0-TSys and travel time t0-TSys therefore applies:
v0-TSys = MIN (v0, vMax-TSys)
t0-TSys = L 3.6 / v0-TSys
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
Road with tram lines One-way road without tram lines Transfer walk link
Car
HGV
Bus
Tram
PuT-Walk
Car
HGV
Bus
Tram
PuT-Walk
Car
HGV
Bus
Tram
PuT-Walk
Car
HGV
Bus
Tram
PuT-Walk
Car
HGV
Bus
Tram
PuT-Walk
Car
HGV
Bus
Tram
PuT-Walk
Car
HGV
Bus
Tram
PuT-Walk
Car
HGV
Bus
Tram
PuT-Walk
Car
HGV
Bus
Tram
PuT-Walk
Car
HGV
Bus
Tram
PuT-Walk
Car
HGV
Bus
Tram
PuT-Walk
Car
HGV
Bus
Tram
PuT-Walk
32 PTV AG
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
(dependent on VD function type)
Result: Current travel time of a transport system = MAX (tCur, t0-TSys)
illustration 13 illustrates how speeds vCur of two PrT transport systems develop depending on
the volume.
Illustration 13: 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 a link is inserted,
this run time is calculated automatically from the link length and the link type-specific speed of
the transport system. During the construction of a system or line route, a suggested run time
between stop points is then calculated from the PuT run time of the link. This in-vehicle time is
in the respective time profile (see "Specifications of lengths and times" on page 51).
2.1.4 Zones
Zones (also traffic cells) are starting point and destination of trips. This means that each trip
starts and ends in a zone. Zones link the transport supply (network model with nodes, links,
PuT lines, etc.) to the transportation demand (in form of demand matrices (see "Matrices" on
page 104), which contain the traffic flows between all OD pairs of the model.
Link type Motorway
vMax (car) = 150 km/h
vMax (HGV) = 100 km/h
Link
v0 = 130 km/h
Free traffic flow
tCur (car) = 130 km/h
vCur (HGV) = 100 km/h
partially linked traffic flow
vCur (car) = 110 km/h
linked traffic flow
vCur (car) = 80 km/h
t
cur
t
0
1 a
q
q
max
c
------------------

b
+

=
130 100
Car HGV
33 PTV AG
Every zone can be assigned a zone boundary 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 33) 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 638). 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 procedure" on page 109).
illustration 14 shows an example of the transport demand between the zones and how they are
available in the demand matrix.
Illustration 14: Transportation demand between zones illustrated in the transport network and as a demand
matrix
2.1.5 OD pairs
OD pairs (or relations) exist between all zones of the network. The values in skim matrices and
demand matrices (see "Matrices" on page 104) each refer to one relation. Compared to the
other network objects, you cannot edit relations interactively in the network editor, but you can
filter relations and display them graphically. For each relation you can select the skim matrix
values, demand matrix values and the direct distance as attributes. Table 7 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.
Note: Zone boundaries are managed (see "The surface data model in VISUM" on page 96)
like surfaces and can consist of multi-face polygons and polygons with holes.
From zone To zone Demand matrix value (1
X)
Skim matrix value (JRT)
100 100 0.00 0.00
100 200 2,000.00 38.00
Table 7: OD pairs in the example Example.ver
34 PTV AG
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.
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.
illustration 15 shows an example of how the travel demand, which is saved in the demand
matrix, is applied between the zones via the connectors to the network.
100 201 200.00 12.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
From zone To zone Demand matrix value (1
X)
Skim matrix value (JRT)
Table 7: OD pairs in the example Example.ver
35 PTV AG
Illustration 15: 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 trip 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.17.1,
page 262). The standard value for the connector speed can be assigned separately for PuT
and PrT connections. 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 272 and "Distribution of the travel demand to PuT connectors" on
page 426). illustration 16 provides an overview of these possibilities and describes each
effect.
36 PTV AG
Illustration 16: 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 aggregated.
Main turns are constituent parts of main nodes. They are created automatically when a main
node is defined.
2.1.7.1 Main nodes
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 illustration would create a lot of work as well as a loss of information, because the
existing refined distribution is required when carrying out microsimulations with the
microsimulation program VISSIM.
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.
Connectors
PrT PuT
Free distribution
(Option: absolute)
- Connector is not li mited by
capacity.
- Impedance for assignment
regards the constant travel
time t0 of the connector
(tCur is not regarded).
Proportional
distribution
(Option: by shares)
Total trips
Each single
OD pair (MPA)
- Assignment regards
connectors j ust as links.
- The capaci ty of a connector
results from the demand share
that is distributed to this
connector.
- In order that the connector is
loaded during assi gnment,
t0 needs to exceed alternative
paths in the network.
- During the i nternal cal culati on
a new zone is created for each
relevant PrT connector
(DSegs with at least a singl e
TSys that may use the
connector).
- Upon these zones, the
demand falls that results from
the connector weights PrT.
- Since each zone has only a
single connector, neither t0 nor
tCur i s regarded for shortest
path search during
assignment.
- The demand of a zone is
distributed to PrT connectors
according to the connector
weights PrT.
Free distribution
(Option: absolute)
- Connector is not limited by
capaci ty.
- Impedance for assignment
regards the constant run time
t0 of the connector.
Proportional
distribution
(Option: by shares)
Each single
OD pair (MPA)
- The demand of a zone is
di stributed to PuT connectors
according to the connector
wei ghts PuT.
- During the internal calculation
a new zone is created for each
relevant PuT connector
(DSegs with at least a single
TSys that may use the
connector).
- Upon these zones, the
demand falls that resul ts from
the connector weights PuT.
37 PTV AG
Illustration 17: Intersection area with multiple nodes
If two roads intersect as in illustration 17 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 does the user follow a turn which represents a left turn and
crosses all other nodes straight ahead. Right turns only touch two nodes, at both nodes they
traverse a right turn, whereas paths leading straight ahead cross four paths. 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. If just one of the nodes belongs to the main node, the link is called a cordon
link. These constitute the access and the egress of the main node: each movement enters the
main node via a cordon link and exits it via a different 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 18: (1))
Cordon links: one of the two nodes belongs to the main node, the other one lies
outside of it (illustration 18: 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:
Inner nodes: only inner links originate here (illustration 18: (3)
Cordon nodes: at least one cordon link originates here, additionally possibly inner links
(illustration 18: (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.
38 PTV AG
Illustration 18: Node and link types of main nodes
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 17, 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 39). 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 39).
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 98).
1
2
3
4
39 PTV AG
Illustration 19: Main turns open to traffic
Illustration 20: Main turns not open to traffic
Within the main node, the main turn takes the place of the network, meaning that the traffic
engineering characteristics, 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.
Use cases for the application of main zones arise in the following situations:
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
Note: Main zone boundaries are managed (see "The surface data model in VISUM" on
page 96) like surfaces and can be made up of multi-face polygons or polygons with "holes".
40 PTV AG
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

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 844) and PuT operating
indicators (see User Manual, Chpt. 7.3.1, page 1075). This means, that the indicator share is
calculated which applies to a territory. Use cases occur especially when calculating PuT
operating indicators.
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 path 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 655), or verify the assignment results.As an option
VISUM saves the assignment of paths found (see User Manual, Chpt. 5.1.2, page 849).
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.22.7, page 318). 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:
Creating an own assignment result either by creating a network file in a text editor or
interactively by digitalizing paths.
Editing an assignment result, 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.
Note: It is currently not possible to calculate assignments or demand models on main zone
level.
Note: Zone boundaries are managed (see "The surface data model in VISUM" on page 96)
like surfaces and can be made up of multi-face polygons or polygons with "holes".
41 PTV AG
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 them 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.22, page 310):
Converting paths (see User Manual, Chpt. 2.22.12, page 323). 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 on paths (see User Manual, Chpt. 2.22.14, page 326). Based on the
matrix and paths, the trips of a matrix are distributed on the paths. This enables them to
change the demand on the level of OD pairs and then distribute the new demand on all
existing paths of the relation, in proportion to the previous shares. Distribution is carried out
with the attribute ActualShareonPathSet. The attribute can be defined for each path by
the user. For each OD pair of a path set the attribute ActualShareonPathSet is first added
up (total weight) on all paths.
Where P is all paths in a path set of origin O to destination D. If for example, there are five
paths from zone A to zone B, the ActualShareonPathSet of the five zones is added up.
The volume of an individual path p then results from the following equation.
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.
TotalWeight ShareOfPathSet
i 1 =
P
=
p.Volume Matrix value
p.ShareOfPathTarget
Total weight
-------------------------------------------------- =
42 PTV AG
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.
Illustration 21: 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.
2
1
H
H
Stop point
at link 1-2
after 50 m
H H
Stop area
Stop
43 PTV AG
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 AVM supply, it is useful to model the stop points on links since
the required degree of detail can be achieved in this way.
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
trips, whose transport system is permitted, can stop there.

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
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
Stop point on node Link stop points
Illustration 22: Possibilities of modeling stop points
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 trip stops always occur at a stop point, each stop has to have at least one stop point.
H
H
H
Directed
stop point on link
Undirected
stop point on link
44 PTV AG
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.

The second function of stop areas is to connect stops to zones and the walkway network
beyond the stop. If required, a network node, which can be reached with the same transfer
walk times as every other stop point of the area, can be assigned to each stop area. The time
within the stop area (diagonal of the transition matrix) is not used for the transition to the access
node. Via this network node, PuT paths can change from a public transport line to links with
PuT walk or additional public transport systems as well as to connections to districts 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 trips 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 PuT trips, 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 trips to jointly evaluate units. An application is for example, the fare/revenue
distribution to the different operators of a public transport system. This often occurs on the
basis of service kilometers or seat kilometers. If you have assigned operators to the trips in
your model, you can evaluate these and many other indicators (see "Operator model PuT" on
page 489).
Operators can either be assigned to a whole line (one then talks about a standard operator) or
individual service trips.

Note: The transfer walk times (transfer walk times matrix) between the stop areas is defined
at the stop.
Note: Please note, that changing the standard operator of a line subsequently, does not
overwrite the operators of existing service trips.
45 PTV AG
2.1.13 PuT vehicles: vehicle units and vehicle combinations
PuT vehicles such as buses, trams or intercity trains are displayed in VISUM, through the
network objects vehicle units and vehicle combination. Using these network objects, it is
possible to change the composition of a service trip en route (see "Network objects of the line
hierarchy" on page 46). This is how a train in the preceding and succeeding trip 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 489).
Each vehicle unit is assigned one or more transport systems. It can only be used for trips, 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 seats and the total number
of seats, cost rates can be entered per distance and time unit, for service trips und empty trips
respectively. 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 permissible transport systems for a vehicle combination is determined as a mean of
the permissible transport system sets of the respective vehicle units. If there is no transport
system which can be combined for all respective vehicle units, these cannot be combined to a
vehicle combination.
Path and time related cost rates can also be specified for each service and empty trips, for
vehicle combinations. These take effect together with the cost rates of the respective vehicle
unit. Use these entry possibilities therefore for such costs, which accumulate only once for
vehicle combinations. Typically, maintenance costs per vehicle should be specified, personnel
costs however, per vehicle combination.
Vehicle combinations can be assigned entire lines or time profiles (one then talks about a
standard vehicle combination) or individual service trips. This enables very detailed modeling
of changes in train formations or also strongly disaggregated evaluation of PuT operator
indicators, for example.

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.
Note: Please note, that the successive modification of standard vehicle combinations of a line
or a vehicle profile, does not overwrite the vehicle combination of the existing service trip
sections.
46 PTV AG
2.1.14.1 Network objects of the line hierarchy
illustration 23 shows the six network objects of the line hierarchy.
Illustration 23: 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 46), nor are run
times specified between the stop points (see "Time profiles" on page 48). 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 standard 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 24). Different line routes
(pairs) of a line represent different route courses, which are organized in lines.
Vehicle journey item
Vehicle journey
Time profile
Line route
Line
Main line
47 PTV AG
Line routes can be generated either manually or based on existing system routes (see "System
routes" on page 58).
Illustration 24: Example for two line routes of a line
Link network Line route 1 Line route 2
M
A
I
N
W
H
S
M
A
I
N
W
H
S
M
A
I
N
W
H
S

S important route point for line
other stop point or node
48 PTV AG
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. It can also contain passage times for any route points of the line route, for
example 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 25). 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.

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 1019).
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.30.4.5, page 408).
Headways for the headway-based assignment are specified on time profile level (see User
Manual, Chpt. 6.9, page 430).
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.
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.
49 PTV AG
Illustration 25: Example for two time profiles of a line route
Service trips (=vehicle journeys)
A service trip describes a planned trip of public transport or a set of planned trips, which are
summarized to an administrative unit of a number. Everyday 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
Line route 1 Time profile 1.1 Time profile 1.2
SPoint Stop Arr Dep. SPoint Stop Arr Dep.
M 0:00 M 0:00
i 1:00 1:02 i - -
N 2:00 2:02 N 1:50 1:52
H 3:00 3:02 H 2:50 2:52
U 5:00 5:02 U 4:50 5:02
O 6:00 O 6:00
M
A
I
N
W
H
S
50 PTV AG
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. Trips cannot, however, switch from
one line route to another. This means that each trip can only run on exactly one line route.
Furthermore, the trip contains a departure time at the origin stop point from which, together
with the relative times of the time profile, all arrival, departure and transit times of the trip 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 489).
Service trip sections (=vehicle journey sections)
Usually there is exactly one vehicle 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 500)
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 illustrated 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
displayed by two vehicle journey sections, which differ in their vehicle combination and start
and end stop points.
Any combinations are possible, for example a train which running 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 500).
Table 8 shows an example with three vehicle journeys of a line route. The line route has two
time profiles. Trip 993 is divided into three vehicle journey sections, which differ in valid days
and vehicle combinations.
[
Trip number from -> to Departure time Valid day Vehicle combination
991 N H 06:02 AM (daily) daily Loco + 6 coaches
992 M H 05:10 AM (daily) daily Loco + 6 coaches
993 M H 06:00 AM (daily) daily Loco + 6 coaches
H S 11:02 AM (Sat+Sun) Sat+Sun Loco + 6 coaches
M N 06:00 AM (Mon-Fri) Mon-Fri 1 additional coach
Line IC1 IC1 IC1
Table 8: Example for three service trips
51 PTV AG
2.1.14.2 Specifications of lengths and times
In conjunction with lengths, different attributes exist at different network objects. illustration 26
illustrates 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.8, page 1244). 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.
The link length can be allocated from the direct distance of the link (see User Manual, Chpt.
2.13, page 212).
The link length can be allocated from the polygon length of the link (see User Manual, Chpt.
2.13, page 212).
When shaping the link, it can be specified, that the link length should comply with the
polygon length (see User Manual, Chpt. 2.13.11, page 227).
You can overwrite the link length in the link list manually for example and thus assign the
link any length (see User Manual, Chpt. 12.1.8, page 1244).
Line route 1 1 1
Time profile 1.1 1.2 1.1
Trip number 991 992 993
Valid day daily daily - Mon-Fri Sat+Sun Mon-Fri
Vehicle combination L+6C L+6C - L+6C L+6C 1C
M dep. - 5:10 6:00
I arr. - | 7:00
I dep. - | 7:02
N arr. - 7:00 8:00
N dep. 6:02 7:02 8:02
W arr. 7:00 8:00 9:00 -
W dep. 7:02 8:02 9:02 -
H arr. 9:00 10:00 11:00 -
H dep. - 11:02 - -
S arr. - 12:00 - -
Trip number 991 requires one service trip section
Trip number 992 requires one service trip section
Trip number 993 requires three service trip sections
Table 8: Example for three service trips
52 PTV AG
Illustration 26: Lengths in VISUM and their coherence
VISUM offers different possibilities to assign times to links and time profiles. illustration 27
provides an overview on how you can influence the run time values for links and time profiles.
The standard value for the link run time for a PuT transport system (t-PuTSys) is calculated
from the quotient of the link length and the link-specific speed of the PuT transport system. The
link run time of the PuT transport system is in turn used as standard value for the run times of
the time profile. The departures and arrivals of a trip 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.8, page 1244).
The run times of the time profile can be edited as follows.
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.8, page 1244).
Length
Link
To Length
Line route i tems
Mulit-Edit Attribute: use Lengt h Di rDist
Muli t-Edit Attri bute: use Length Pol ygon
When editing the shape of the link: Take over Length-Polygon
Set lengths: uses the length of the link
Manual overwriting
Standard
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 ti me profile). To do this, please use the suitable functionality on the right-hand side (such as Set
times: from li nk run time)
Legend
Manual overwriting
Connecti on between lengths
53 PTV AG
Illustration 27: 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 trips and their trip 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 trips take place.
Alternatively, the trip service can also be described through line routes, time profiles and a
regular service per time profile (see "Headway-based assignment" on page 430). In this case
we are also taking about a timetable in VISUM.
Due to this hierarchical setup of the timetable, is it possible to reuse the data for similar trips in
a different way. Otherwise, the exact route would have to be specified for each individual trip
via the network 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.
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 service trip section must match at any point of time. A run time between two
Link length
Link type-specific speed of the PuTSys
Link run time t-PuTSys
Link
run time
Time profi le
Departure/ Arri val
Vehi cl e j ourney
Generating link run times from li ne run ti mes
Standard val ues
Manual overwriting
Set times: from l ink run time
Set times: from system route
Set times: from link attribute
Set times: from time profil e item attribute
Manual overwriting
Standard
Standard
Standard
Auto
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 ti me profi le). To do this, please use the suitable functionality on the right-hand side (such as Set
times: from l ink run ti me)
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.
Legend
All ocation of run ti mes
54 PTV AG
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, an individual line route and time profile are created for each
individual trip. Essential advantages of the hierarchical setup of the VISUM PuT model are thus
lost, such as the reuse of line route data for many trips. 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.
illustration 28 shows examples of cases in which aggregation is possible and in where not.
Illustration 28: Example for the aggregation of line routes
As an option, aggregating line routes can be made more difficult with the following conditions.
A B C D
B C
A B C
A B C D
A B C D
B C D
A B C D
E
B C D
A B C D
A B C
F
A B C D
A B C D
G
Line routes to be aggregated Aggregated line routes
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
55 PTV AG
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 permissibilities for access and egress.
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. In order to couple two line routes on a
section, the stop points of the time profiles of the coupled line routes have to match, whereas
the run times and the dwell times on the coupled section do not necessarily have to be
identical. If required, they are adjusted.
Illustration 29: Examples: Coupling two and three line routes
The number of line route services (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 trips (see User Manual, Chpt. 2.42, page 563)
Inserting and deleting trip sections (see User Manual, Chpt. 2.42, page 563)
H2
H4
H6
L1-1
L1-2
H1
H3
H5
H1
H3
H4
L1-1
L1-2
H5
L1-3
H2
H1
H3
H6
L1-1
L1-2
L1-3
H5
H2 H4
H4
L1-1
L1-2
H1 H2 H3
56 PTV AG
Changing the extension of trips (see User Manual, Chpt. 2.42, page 563)
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.
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.
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 609). On which indicators exactly they have an effect on
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.
57 PTV AG
Illustration 30: Calculation example for the calculation of indicators in case of couplings
Number of trips 10 trips
Empty time 10 min/trip
Kilometer costs 1 euro/km
Hourly costs 60 euro/h
Track price 1 euro/km
Seats 100 seats/vehicle combination
Table 9: Input data for the calculation example
Not coupled Not coupled isCoupled isCoupled
Line route L1-1 L1-2 L1-1 L1-2
ServiceKm 1,300 km 1,300 km 1,050 km 1,050 km
SeatKm 13,000 km 13,000 km 13,000 km 13,000 km
Service time 900 min 1,000 min 750 min 850 min
Out-of-depot time 1,000 min 1,100 min 850 min 950 min
Costs 1,300 euros 1,300 euros 1,050 euros 1,050 euros
Costs 1,000 euros 1,100 euros 850 euros 950 euros
Track costs 1,300 euros 1,300 euros 1,050 euros 1,050 euros
Total cost 3,500 euro 3,600 euro 2,950 euro 3,050 euro
Num Service Trips 10 10 10 10
Table 10: Calculation of indicators for the line route
H2
H4
H6
L1-1
L1-2
H1
H3
H5
50 km
30 min
40 km
40 min
40 km
30 min
50 km
30 min
40 km
30 min
40 km
30 min
58 PTV AG
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 trip.
This travel time and route information can be used in two ways for creating a timetable.
Editing the shape of a line route with system routes
Travel times of existing line routes and time profiles are composed of system routes
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.
Link H2-H3 H3-H4 H2-H3 H3-H4
ServiceKm 1,000 km 400 km 500 km 400 km
Num Service Trips 20 10 10 10
Table 11: Calculation of indicators for the links
59 PTV AG
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.
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).
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 87). illustration 31 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 702).
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 96).
60 PTV AG

Illustration 31: Reachability analyses for secondary schools
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.33.1,
page 450). 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 AVL systems
SC controller among other things
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.2.3.7, page 1272). In the example of illustration 32 allocations are used to illustrate for
parking lots in a downtown area which links the approaches lead to.
61 PTV AG
Illustration 32: 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 1149).
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.
A detector illustrates a lane-related count direction. It breaks down the count data of a count
location precisely by lane. The detector is identified by its number and has in addition to code
and name a geographic position, specified by a pair of coordinates. It is not assigned to a link,
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.
62 PTV AG
but optionally a count location and thus indirectly a link. The number of observed lanes is
determined by the attribute Observed lanes, the observed lane furthest to the right,
determined by the attribute Lane position.
If a detector is assigned to a count location and therefore a link, the observed lanes have to be
compatible with the number of link lanes, which means that no lane is allowed to be observed
which is not defined on the link. With a lane number of 2 the detectors for lanes 1 and 2 are
allowed to be defined. It is however permissible, that a lane is observed by several or no
detectors.
Count locations and 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 87). 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 179).
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. illustration 33 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.
Illustration 33: Visualization of the local position of count locations with the date of the count
63 PTV AG

2.1.18 Toll systems
Toll systems are optional network objects which can be used to integrate toll zones and tolls
into the network model (see User Manual, Chpt. 2.37, page 476). They represent the (see
"Basics of the assignment with toll consideration" on page 355)basis for the calculation of road
tolls in the Tribut procedure .
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. They are also relevant for signal-controlled nodes or the ANM
export to VISSIM.
64 PTV AG
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 to any trip including a portion 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.
Illustration 34: The Congestion Charge in London is an area toll
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.
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 Geo Database (PGD) connection (see
"Connection to the Personal Geo Database and GIS objects" on page 633). This is how GIS
data can constantly be synchronized between the PGD and VISUM.
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 82).
Number of links which intersect the screenline.
65 PTV AG
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 35: Summation and average calculations with screenlines
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 36 149.334 vehicles of the PrT enter the downtown area and
76.370 persons in PuT.
66 PTV AG
Illustration 36: 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 838). 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 microsimulation in VISSIM.
Element Description
Topology Topologies are used to describe the geometry of nodes and main nodes in
detail. The principal elements of topologies are legs.
Table 12: Network objects of the Junction model
67 PTV AG
2.1.21.1 Link orientations
Link orientations play an essential role when defining node topologies (see "Topologies" on
page 68). The link orientations are used to determine the amount of legs. Each link has four
orientation attributes, namely 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 36). 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 topology 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
roads and outgoing one-way roads in one leg (see "Topologies" on page 68), 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.13.4,
Leg A leg topology 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 turns 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 signal group-based and stage-based signal
controls.
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.
Element Description
Table 12: Network objects of the Junction model
68 PTV AG
page 215). 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).

2.1.21.2 Topologies
In macroscopic traffic models, an at-grade junction is represented by a node (point object) with
turns. The macroscopic modeling does not reveal anything about the exact topology or the
geometric layout of an intersection. Nearly the same applies to the node control. The optional
enhancement of the VISUM network model by the node topology and the junction control can
be used in the following fields:
Calculating the performance at a node
Considering node impedances during assignment
Providing entire intersections for the microscopic model VISSIM
A node topology consists of the items node legs, lanes, lane turns, and crosswalks. If a signal
control is allocated to a node, its data refer to the node topology. By default, no topology data
are provided at a node. These are generated not until the first access.
Legs
The principal elements of the topology 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 66). 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.
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
(attribute Number of lanes at 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
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.
69 PTV AG
topology 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.
Lane turns
A lane turn connects an incoming lane with an outgoing lane. When generating a topology
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 leg has, for
example, 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 employing ICA (see "Intersection
Capacity Analysis according to the Highway Capacity Manual (ICA)" on page 213).
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 topologies 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
Note: The numbering of the lanes differs from the one in VISSIM.
70 PTV AG
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 controls
Signal controls (SCs) can be allocated to signalized nodes and main nodes (attribute Control
type has the value Signalized). There are three types of SCs: signal group based, stage
based and 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 71).

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 (HCM 2000
Chapter 16)" on page 214). In case 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 the
attributes Green time start and Green time end have value 0 at a signal group or a stage, and
the attribute Green time end is identical to the cycle time of the SC, this will be 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. The green time is determined by
subtracting the difference of both values from the cycle time of the SC. 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 attribute Used intergreen method of the signal
control determines whether the amber and allred time or the intergreen matrix is used for
optimization. The attribute ICA loss time adjustment 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 attribute VISSIM coordinated 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
Note: An SC can be allocated to multiple nodes or main nodes. This is not recommended
though, because then the Signal cycle and split optimization operation does not yield good
results. 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.39.14.1, page 539).
71 PTV AG
Chapter 2.2:Spatial and temporal correlations in VISUM
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 node models (see User Manual, Chpt. 2.40, page 545).
External controls
A special feature of external SCs is that the data are not saved in the version file. The data are
saved in control files of the format *.sig. This way, they can also be accessed by other
programs, for example VISSIM. The program VISSIG is used in VISUM to edit external control
data. 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.
Stage templates
Stage templates can be used to easily generate signal control data at a node or main node
(see User Manual, Chpt. 2.39.13.2, page 535). 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.

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.40, page 545).
2.2 Spatial and temporal correlations in VISUM
In VISUM, the following can be specified:
Calendar
Valid days
Time series
Analysis time intervals
2.2.1 Calendar and valid days
You can specify a calendar and valid days for your network.
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.
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.
72 PTV AG
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:
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.
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 service trip 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 of July 2008 to 20th of 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. Time-
varying attributes are used (see "Time-varying attributes" on page 90). 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.
A valid day is a freely definable set of days within the used calendar. If a weekly calendar is
used, a valid day can, for example, span the days Monday to Friday (the valid day can then be
called Monday to Friday for example).
The timetable in PuT is based on a calendar (see "Calendar" on page 72). 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 service trip sections can be specified by valid days. A valid day is a
freely definable set of days of the underlying calendar. Each valid day can be assigned its own
name. Valid days usually represent regularly recurring patterns, such as Monday to Friday, but
73 PTV AG
these could also be individual days (for example 01.01.2009). How to define a valid day
depends of the selected calendar:
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).
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:
(see "Dynamic stochastic assignment" on page 396)Dynamic Stochastic assignment
Dynamic User Equilibrium (DUE) (see "Dynamic User Equilibrium (DUE)" on page 367)
Metropolis (see "NCHRP 255" on page 402)

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.

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.
There are two different types of so-called standard time series which have to be defined in
VISUM:
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,
Tip: In these procedures, the transport supply can be time-varying. Time-varying attributes
are used (see "Time-varying attributes" on page 90). When using a calendar, valid days can
be specified for these time-varying attributes, on which they should have an affect.
Note: A time series must be allocated to the demand segments in order to calculate an
assignment with these procedures.
74 PTV AG
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.
Illustration 37: 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 38: Time series of matrix numbers

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.
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.
75 PTV AG

2.2.3 Time reference of volumes: analysis time intervals 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 intervals are provided in VISUM.
The 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 635).
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).
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
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.
76 PTV AG
valid day (for the operator model) (see "Basic calculation principles for indicators" on
page 603). 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 always the sum of
the volumes of all paths which lead via this network object, multiplied by the projection
factor of the demand segment. This projection factor compensates that the assignment
time interval might just cover 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 79). Each analysis
time interval needs to lie completely within a calendar day of the analysis period.

Illustration 39: The relationship between the different analysis time intervals
Example for 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 days, Saturday and Sunday.
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. The projection factors of the individual demand
segments thus do not affect the volume per analysis time interval. If the analysis period is
covered entirely by the analysis time interval, the ratio of the sum of all volumes of the
intervals for the volumes based on the analysis period is in strict conformity with the
projection factor.
Day n
Day 1
Calendar period CP
DSeg 1
DSeg i
Analysis period AP in CP
Analysis time interval AI in AP
AP
AI
ATI
Assignment time interval ATI in AP
Demand segments
Demand starts at start ti me of DSeg + from_ti me of standard time series
77 PTV AG
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.
Example for the interaction of analysis time periods 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 40),
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
interval. No connections calculated. In the second (illustration 41) and third example
(illustration 42) assignment time interval and validity period of the demand overlap, so that an
assignment can be calculated. Table 14 provides an overview on analysis time intervals and
time series of the three examples.
Demand segment Projection factor AP Projection factor AH
Standard working day 5
Saturday 1 52
Sunday 1 52
Table 13: Deriving projection factors for AP and AH
Calendar Assignment
time interval
Analysis
period
DSeg
start day
DSeg
start
time
Standard
time series
from
Standard
time series
to
Assignme
nt can be
calculated
Ex. 1 Weekly
calendar
Mo. 6:30-
7:30
Mo. - Mo. Mo. 01:00:00 00:00:00 02:00:00 No
Ex. 2 Weekly
calendar
Mo. 6:30-
7:30
Mo. - Mo. Mo. 05:30:00 00:00:00 02:00:00 Yes
Ex. 3 Weekly
calendar
Mo. 6:30-
7:30
Mo. - Mo. Mo. 00:00:00 05:30:00 07:30:00 Yes
Table 14: Example for the interaction of analysis time intervals and time series
365
7
-------- - 5 260 =
78 PTV AG
Illustration 40: Assignment not possible because the validity of the demand and the assignment time
interval do not overlap
Illustration 41: The demand between 6:30 and 7:30 am is assigned
Calendar period CP
AP
Assignment interval AI in AP
Time series of the
demand segment
Mo Tu
6:30 7:30
1:00 3:00
AI
Calendar period CP
AP
Time series of the
demand segment
Mo Tu
6:30 7:30 5:30
AI
Share of the demand
that is assigned
79 PTV AG
Illustration 42: The demand between 6:30 and 7:30 am 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 189). 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 intervals (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 trips served by a specific line using low-floor buses between 6:00 and 7:00 am 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 824). 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 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 367 and "Dynamic stochastic assignment" on page 396). 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
Calendar period CP
AP
Time series of the
demand segment
Mo Tu
6:30 7:30 5:30
AI
Share of the demand
that is assigned
DSeg
Start time
Mo. 00:00
80 PTV AG
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 40). 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 844). The results can be displayed in the list
Territories > Basis (see User Manual, Chpt. 12.1.8, page 1244) 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 489). 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 1075). The results can be displayed in the Territories > PuT detail list (see User
Manual, Chpt. 12.1.8, page 1244).
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.
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 195).
2.3 Attributes
In VISUM there are the following types of attribute:
81 PTV AG
Chapter 2.3:Attributes
Direct attributes
Indirect attributes
User-defined attributes
Time-varying attributes
2.3.1 Direct attributes
Each of the network objects is described by means of VISUM attributes (direct attributes). The
following types are differentiated as follows:
Input attributes (for example Stop number) and
calculated attributes, which are also called output attributes (for example 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)

The Table 15 shows an example of some input and output attributes of the link.
Apart from predefined VISUM attributes, for each network object type, user-defined attributes
(see "User-defined attributes" on page 87) can be created and edited. They are also direct
attributes of the respective network object type and 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 90).
Note: The Attribute.xls file in the Doc directory of your VISUM installation contains the
complete list of all VISUM network object types (which are also designated as tables in
connection with databases) and all attributes of each network object. You will find each ID
there, which clearly identifies the attribute, as well as its name and code and a description,
what the attribute means.
Attribute Input attribute Calculated attribute
Number X
TSysSet X
Capacity PrT X
Number of lanes X
t0-PrTSys X
tCur-PrTSys X
Capacity PrT [Veh] X
Saturation PuT seats X
Passenger kilometers X
Table 15: Examples of input and output attributes at the link
82 PTV AG
2.3.2 Indirect attributes
In addition to direct attributes of the currently selected network object, users can also access
indirect attributes (read-only). These are direct objects of other network object types that are
network model-related to the selected object. Therefore, for a marked 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.
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
in Table 16, 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.
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 17, 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 Zone\Number of
connectors in the attribute selection window
Display of indirect attributes in the table right next to
the attributes of the connector
Table 16: Example for a 1..1 relation in the VISUM network model
83 PTV AG
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:
Num and NumActive
Determine the number of associated network objects. In Table 18, the number of stop
areas associated with a stop is determined.
Min and MinActive
Determine the minimum value of all associated network objects for the selected attribute.
In Table 19, the minimum number of boarding passengers at all stop points of the stop area
is output.
Selection of the indirect attribute Main node\Name
in the attribute selection window
the attributes of the node
Table 17: Example for a 0..1 relation in the VISUM network model
Selection of the indirect attribute Num: Stop areas
in the attribute selection window for stops
the attributes of the stop
Table 18: Example for a 0..n relation with aggregate function Num
84 PTV AG
Max and MaxActive
Determine the maximum value of all associated network objects for the selected attribute.
Table 20 displays the maximum number of boarding passengers at all stop points of the
stop area.
Sum and SumActive
Determine the total of the values of all associated network objects for the selected attribute.
Table 21 displays the total of boarding passengers at all stop points of the stop area.
Selection of the indirect attribute Min:Stop
points\Passengers boarding(AP) in the attribute
selection window
the attributes of the stop area
Table 19: Example for a 0..n relation with aggregate function Min
Selection of the indirect attribute Max:Stop
selection window
Table 20: Example for a 0..n relation with aggregate function Max
85 PTV AG
Table 21: Example for a 0..n relation with aggregate function Sum
Avg and AvgActive
Determine the mean of the values of all associated network objects for the selected
attribute. Table 22 displays the average number of boarding passengers at all stop points
of the stop area.
Selection of the indirect attribute Sum:Stop
selection window
Selection of the indirect attribute Avg:Stop
points\Passengers boarding(AP) in the
attribute selection window
Table 22: Example for a 0..n relation with aggregate function Avg
86 PTV AG
Concatenate and ConcatenateActive
String all values of the associated network objects together for the selected attribute.
Table 23 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.
Histogram and 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. Table 24 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.
Selection of the indirect attribute
Concatenate:Stop points\Passengers
boarding(AP) in the attribute selection window
Table 23: Example for a 0..n relation with aggregate function Concatenate
87 PTV AG
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 638).
2.3.3 User-defined attributes
For all network object types it is possible as for databases or GIS - to define UDAs in addition
to the input and output attributes predefined 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.
Structural data of traffic zones (such as the number of households or the number of
workplaces), which serve as input data for demand modeling.
Selection of the indirect attribute
Histogram:Line routes\Number stop points
in the attribute selection window
Display of indirect attributes in the table right next to the
attributes of the line
Table 24: Example for a 0..n relation with aggregate function Histogram
88 PTV AG
Illustration 43: Structural data of zones stored in user-defined attributes
Count data of links over several years (e.g. DTV2005, DTV2006)
89 PTV AG
Illustration 44: Count data stored in user-defined link attributes
Different categories of line services
User-defined attributes for storing calculation results from Multi-Edit operations (see User
Manual, Chpt. 2.8, page 153). Table 25 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.
Each user-defined attribute has a 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)
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 25: Saving the cost per kilometer to a user-defined attribute
90 PTV AG
File (for example for a user-defined attribute at count locations which specifies which file
contains further information on the count location)
Integer
Number with decimal places
Kilometers
Meters
Long text
Text
Time period
Time (for example 06:32:45)
2.3.4 Time-varying attributes
In the procedures DUE (see "Dynamic User Equilibrium (DUE)" on page 367), dynamic
stochastic assignment (see "Dynamic stochastic assignment" on page 396) and Metropolis
(see "NCHRP 255" on page 402), time-varying traffic supply can be modeled. In VISUM, time-
varying attributes are used for this purpose. Time-varying attributes only affect these three
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-dependant 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. Table 26 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 396) and DUE (see "Dynamic User Equilibrium (DUE)" on page 367).
Network object Time-varying attribute Dynamic
Stochastic
Assignment
DUE
Links Out capacity PrT X
Capacity PrT X X
Toll-PrTSys X
v0 PrT X X
TSysSet X
AddValue 1...3
Table 26: Time-varying attributes and their allocation to assignment procedures
91 PTV AG
The example in Table 27 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).
AddValue-TSys
Turns Capacity PrT X X
ICA final capacity
t0 PrT X
TSysSet X
AddValue 1...3
Main turns Capacity PrT X X
t0 PrT X
TSysSet X
AddValue 1...3
Nodes Capacity PrT X
t0 PrT X
AddValue 1...3
Main nodes Capacity PrT X
t0 PrT X
AddValue 1...3
Table 26: Time-varying attributes and their allocation to assignment procedures
92 PTV AG
The links 11 - 41 and 41 - 40 are charged with the full capacity of 800.
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 27: Impact of time-varying attributes in the Dynamic Stochastic assignment
93 PTV AG
Chapter 2.4:Subnetwork generator
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:
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 the nodes, including all legs located within
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 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
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 vehicle journey items of the 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.
Demand segments
Modes
Transport systems
Link types
94 PTV AG
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 *
* when activating option Include the demand model in the subnetwork
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 subnetwork 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
95 PTV AG
Chapter 2.4:Subnetwork generator
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.
The following applies to both matrices regarding path legs and those regarding paths. If the
transport system PuTAux is used in a PuT assignment, the subnetwork generator manages
routes that contain PuTAux as follows:
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 transport system PuT Walk: 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 45 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.
Illustration 45: Generating a subnetwork with stop point matrices regarding path legs and stop point
matrices regarding paths
Zone
Node
Stop point
Walk link via active links
Path leg on active line route
Zone
Node
Stop point
Walk link via active links
Path leg on active line route
Stop point matrix (regarding path legs)
Stop point matrix (regarding paths)
External zone
Stop point matrix (regarding path legs)
Stop point matrix (regarding paths)
External zone
12 13 14 15 16 17
Stop point matrix:
12 13 14 15 16 17
Stop point matrix:
12 14 15 18
Stop point matrix:
18
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
12 13 14 15 16 17 18
12 50
13 50
14
15 50
16
17 50
18
12 14
12 14 15 18
Stop point matrix:
18
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
12 13 14 15 16 17 18
12 50
13 50
14
15 50
16
17 50
18
12 14 15 18
12 50
14
15 50
18
1
Walk link (via at least one passive link)
Pathleg on passive line route
12
96 PTV AG
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 (see "Tables in the surface model" on page 96).
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

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 Ds 866, 867 and 868 (Table 28).
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 29).
Note: In VISUM, it is possible to save the polygons per network object type to a network file
(see User Manual, Chpt. 1.3.3, page 39).
* Tabl e: Mai n nodes
$MAI NNODE: NO; SURFACEI D
2; 866
3; 867
4; 868
Table 28: Table Main nodes
* Tabl e: Sur f aces
$SURFACE: I D
866
867
868
Table 29: Table Surfaces
97 PTV AG
Chapter 2.5:The surface data model in VISUM
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. There are thus four faces in total with the IDs 1139,
1141, 1144 and 1145 (Table 30).
In the Faces table, all faces contained in the network are stored with their IDs. In this example,
there are thus four faces (Table 31).
In the Face items table, each face is allocated the IDs of the edges which define the face. As
you can see in Table 32, 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.
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 33).
* Tabl e: Sur f ace i t ems
$SURFACEI TEM: SURFACEI D; FACEI D; ENCLAVE
866; 1139; 0
868; 1141; 0
869; 1144; 0
869; 1145; 0
Table 30: Table Surface items
* Tabl e: Faces
$FACE: I D
1139
1141
1144
1145
Table 31: Table Faces
* Tabl e: Face i t ems
$FACEI TEM: FACEI D; I NDEX; EDGEI D; DI RECTI ON
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 32: Table Face items
98 PTV AG
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 34).
No intermediate points were generated in the example. The table is therefore empty
(Table 35).
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
* Tabl e: Edges
$EDGE: I D; FROMPOI NTI D; TOPOI NTI D
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 33: Table Edges
* Tabl e: Poi nt s
$POI NT: I D; 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 34: Table Points
* Tabl e: I nt er medi at e poi nt s
$EDGEI TEM: EDGEI D; I NDEX; XCOORD; YCOORD
Table 35: Table Intermediate points
99 PTV AG
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).
Illustration 46: 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. Table 36 shows some examples for
the normalization of surfaces.
Specified surface Normalized shape of the surface
1
Two separate faces
OK the surface remains unchanged
2
Two overlapping faces not OK both faces have been merged
Table 36: Examples for the normalization of surfaces
a
n
ti-c
lo
c
k
w
is
e =
p
o
s
itiv
e
c
lo
c
k
w
is
e =

n
e
g
a
tiv
e
anti-clockwise
= positive
100 PTV AG
A surface is thus "normalized if the following conditions are met.
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).
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.
3
A face with a hole OK the surface remains unchanged
4
A face with a hole which intersects the
boundary of the surface
not OK the hole is omitted and the face
adjusted
5
A face with an intersecting boundary not OK the negative part is deleted
Specified surface Normalized shape of the surface
Table 36: Examples for the normalization of surfaces
101 PTV AG
When does the program normalize?
Since normalized surfaces are required for efficient processing of polygons in various
geometrical operations, VISUM needs to check and restore this property by transforming the
input data (where applicable) when loading surfaces from network files or when interactively
editing the shapes of polygons.
All of 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. The same applies when reading in network files.
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 36,
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 36, 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 36, 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 36,
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.
102 PTV AG
103 PTV AG
3 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 Four-Stage Model (see "Standard Four-Stage Model" on page 110)
EVA (see "EVA Model for Passenger Demand" on page 115)
VISEM (see "Activity chain based model (VISEM)" on page 144)
The result of this procedure 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 195 and "User Model PuT" on page 407).
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 104)
temporal distribution of the demand by specifying a time series (see "Time series" on
page 105). 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 104)
There are several demand objects(see "Demand objects" on page 103) 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
Demand objects
Demand modeling procedure
Displaying and Editing Matrices
Matrix correction
3.1 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.
Matrices
104 PTV AG
Chapter 3: Demand model
Demand segments
Time series
Demand model structure
Population groups
Activities, Activity Pairs, Activity Chains
Demand strata
In addition, the EVA and VISEM demand models also contain the demand structural properties
(see "Structural properties" on page 115 and "VISEM Data model" on page 144).
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 115)
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 105). 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 157).
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.

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 24).
Demand segments are different from demand strata (see "Demand strata" on page 108).
Demand strata contain demand groups for the steps trip generation, trip distribution and mode
choice of the Standard Four-Stage Model. Another important difference is that each demand
segment is assigned to exactly one mode (for example PrT or PuT).
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.
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.
105 PTV AG
Chapter 3.1: Demand objects
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 104). 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 105). VISUM establishes the link between demand and transport supply.

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 73).

There are two types of standard time series:
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
3.1.4 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 "Demand model" on page 3).
A demand model has the following attributes:
3.1.5 Population groups
The population living in the planning area is broken down into so-called behavior-
homogenous groups. The traffic behavior of the different groups should be clearly different,
but within the individual groups it should be as homogenous as possible.
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.
Note: A time series can also be assigned to several demand segments.
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-Stage-, EVA Passenger Demand or
VISEM Model)
ModeCodes Abbreviation of the modes of the demand model
106 PTV AG
This documentation uses examples in which the population 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).
The demand object person group is described by the following attributes:
When using the Standard-Four-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.
The demand object activity is described by the following attributes:
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 Class Pas
Primary school pupils PPup
Children under six Child
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
Work A
Shopping E
Education: vocational school B
Education: university U
Education: secondary school. Class S
Education: primary school P
Recreation F
Home H
Code (Key) Code (any string), for example W
107 PTV AG
Chapter 3.1: Demand objects
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:
The following attributes describing activity pairs are only relevant for EVA models.
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.
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. EVA-
P.
Note: Activities are optional and can be defined interactively only for EVA and VISEM models.
In case of Standard-Four-Step models one activity corresponds to exactly one activity pair.
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.
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 118 and "EVA Trip Distribution
and Mode Choice" on page 135).
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
108 PTV AG
In the VISEM demand model, the average mobility program of persons is described by activity
chains. The Standard-Four-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
VISEM with exactly one person group). The pointers to activity chains and person groups in the
Standard four-stage model are optional.
The correlations between demand objects can be depicted graphically as follows (see
"Correlations between different demand objects" on page 108).
Illustration 47: Correlations between different demand objects
The demand object demand stratum has the following attributes.
DemandModelCode Abbreviation of the demand model the person group belongs to (any string), for
example DEFAULT.
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
DemandModelCode Abbreviation of the demand model, for the respective demand
stratum, for example DEFAULT
Activity Pair
e.g. HW
Activity Chain
e.g. HW-WH
m
Demand Stratum
e.g. HW-WH x E+c
Standard-4-Step Model
and EVA Model:
1 : 1 (=Activity Pair)
Person Group
e.g. E+c
Person group or
Household group
1
n
n
m
Activity
e.g. Work
OrigActivity DestActivity
n
1 1
n n
109 PTV AG
Chapter 3.2: Demand modeling procedure
The following attributes describing demand strata are only relevant for EVA models.
3.2 Demand modeling procedure
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.
Standard Four-Stage Model
EVA Model for Passenger Demand
Activity chain based model (VISEM)
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).
Origin Structural Property Codes Origin of the structural property codes
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
This Boolean attribute describes, whether the lower or upper limit
of the production and attraction is constant (=1) or zone-dependant
(=0).
Constraints min factor origin
Constraints max factor origin
destination
Constraints max factor
destination
Factor for the upper or lower limit of production or attraction.
110 PTV AG
There are also the following functions available to calculate the transportation demand:
Estimate gravitation parameters (KALIBRI)
Gravity model calculation
Modal Split (standardized assessment)
Iteration
3.2.1 Standard Four-Stage Model
The first three stages of the Four-Stage Model, Trip generation, Trip distribution and Mode
choice, are usually carried out sequentially in the Standard Four-Stage Model successively. As
illustration 48 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 stages (including Assignment) is repeated until the result fulfils 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 the Go to the Operation .(see "Go to
the operation" on page 169)
Illustration 48: Integrated four-stage demand model in VISUM
Per demand stratum
Trip generation
Trip distribution
Mode choice
production
rates
zone
attributes
(inhabitants,
jobs)
skim
matrix
utility
function
utility
function
skim matrix
per mode
demand
matrix
demand
matrix
demand
matrix
demand
matrix
demand
matrix
Assignment Assignment Assignment
production
& attraction
(per zone)
Per
demand
segment
111 PTV AG
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 169 and "Method of Successive Averages over attributes" on
page 169).
As variant of the classical four-stage 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 49 shows as an example the procedure in an extended demand model.
Illustration 49: Extended four-stage 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 170).
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 directly to the actual origin traffic of the zone, this means, the number of trips
starting there, or it merely reflects the attractiveness of the zone for the demand stratum and
therefore influences the probability that in the following Trip distribution trips will start in that
zone. 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
112 PTV AG
appropriate, perhaps broken down into different sectors. For such skims user-defined zone
attributes are the best. First, production Q
i
of zone i is calculated with the help of a formula,
whereby SG
g
is summed up across all structural properties. SG
g
(i) corresponds to the value of
SG
g
in zone i. The coefficient
g
is a production rate that shows the number of trips per
structural property unit. They specify the production rates per demand stratum and zone
attribute used. The same calculation is performed for the attraction Z
j
.
In most applications the total production of a demand stratum (added up over all zones)
corresponds to the total attraction.
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 subnetwork 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.5.5.2, page 137)) 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 157).
( )
=
g
i
g
SG
g i
Q

=
i j
j
Z
i
Q
113 PTV AG
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 mode-
specific 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.
The following applies:
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 157). As an example see below the calculation for the Logit model.
whereby T
ij
is the total number of trips of the demand stratum in the relation i-j, T
ijm
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.
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 156).
c
ijmg
The impedance of the cost type g for the trip from zone i to zone j by mode m.
=
g
ijmg
c
g ijm
U
ij
T
ijm
p
ijm
T
k
U c
e
U c
e
ijm
p
ijk
ijm
=
114 PTV AG
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 50).
Illustration 50: 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 112 and "Mode choice" on
page 113). 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.
115 PTV AG
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.
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 Four-Stage
Model" on page 110) 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 103) 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 118).
Activities and Activity pairs
In the EVA Model activities and activity pairs have the following additional attributes.
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.
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
116 PTV AG
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.
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.
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
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)
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)
117 PTV AG
Zones
Due to the definition of the objects of the demand model several zone attributes are created.
origin constant
(CF OMax constant on
the user interface)
As above for the upper limit on origin side
Range: bool (0, 1)
(CF OMin constant on
the user interface)
As above for the lower limit on destination side
Range: bool (0, 1)
(CF DMax. constant on
the user interface)
As above for the upper limit on destination side
Range: bool (0, 1)
origin
(CF OMin Constant 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
origin
(CF OMax constant on
the user interface)
As above for the upper limit on origin side
destination
(CF DMin on the user
interface)
As above for the lower limit on destination side
destination
(CF DMax on the user
interface)
As above for the upper limit on destination side
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.
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.
Attribute Meaning and range of values
118 PTV AG
3.2.2.2 EVA trip generation
In the EVA model and Standard-four-stage 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
origin
Demand stratum As above for the upper limit on origin side
destination
Demand stratum As above for the lower limit on destination side
destination
Demand stratum As above for the upper limit on destination side
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
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.
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.
Attraction rate Demand stratum
Structural
property
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.
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.
Study area factor
destination
Demand stratum
Structural
property
119 PTV AG
demand matrices available at the end of the model chain only can be combined with an
empirically determined or standardized daily time series (illustration 51) to get the shares of
demand for the individual times of the day. The daily time series depend on the demand
stratum.
Illustration 51: 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, B: School; D: Service; O: Shopping; P: Private/leisure;
S: Miscellaneous.
From/To H A C B D E F S
H HW HC HS HF HP HR HO
A WH WO
C CH
B SH
D FH
E INH
F RH
S OH OW OO
Table 37: Typical break-down of a demand stratum into 8 activities and 17 demand strata = activity pairs
Demand stratum Structural property (S) / Person group (P) of source zone i
HW P Employees
HC P Young children
HS P Pupils, apprentices, students
HF P Employees
HP P Inhabitants
120 PTV AG
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
HR P Inhabitants
HO P Inhabitants
WO S Jobs
WH S Jobs
CH S Jobs / capacity
SH S Jobs / capacity
FH S Jobs
INH S Jobs / sales floor
RH S Jobs / capacity
OH S Other jobs
OW S Other jobs
OO S Other jobs
DStr Structural property (S) / Person group (P) of destination zone j
HW S Jobs
HC S Jobs / capacity
HS S Jobs / capacity
HF S Jobs
HP S Jobs / sales floor
HR S Jobs / capacity
HO S Other jobs
WO S Other jobs
WH P Employees
CH P Young children
SH P Pupils, apprentices, students
FH P Employees
INH P Inhabitants
RH P Inhabitants
OH P Inhabitants
OW S Jobs
OO S Other jobs
Table 38: Examples of relevant structural properties and person groups of the demand strata
Demand stratum Structural property (S) / Person group (P) of source zone i
121 PTV AG
destination. An example of the allocation of certain structural properties to individual demand
strata is illustrated by Table 38.
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.
In most cases, the MR
pc
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 MR
epc
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 MR
ET,WA
. 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 U
R,ET,WA
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: U
Z,ET,WA
= 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 U
R,EoP,WA
> U
R,EmP,WA
. And in analogy
hereto would be U
R,KK,WK
> U
R,EmP,WA
, 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
.
pc
MR
p group person of persons of Number
p group of persons by DStr in trips of Number
=
122 PTV AG
trips of the study area. Therefore, in that case, too, the total structural potential is multiplied by
a study area factor V
R,B,WA
< 1.
In the trip generation stage (Table 39, Table 40 and Table 41) from the structural data and
values mentioned for all demand strata c, the productions Q
ic
and attractions Z
jc
or the upper
limits Q
ic
max
and Z
jc
max
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 39, Table 40 and Table 41. 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).
123 PTV AG
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 39, Table 40 and Table 41 the calculation formulas are listed up separately for the
cases for which they differ.
Step 1 Home trips H
Step 2 Production Q, Qmax
Step 3 Total volume V
Table 39: Trip generation in EVA model: OD type 1
=
=
P p
epc ep epc ec
epc ep epc epc
u BP MR H
u BP MR H
H
Q
ic
ic
=

=

=
=
n
1 S s
sc
v
s
SG
sc
ER
c
V
c
f
m
1 i
ic
=
c
V
Q
l
l l l
124 PTV AG
Step 4 Attraction Z, Zmax
Step 1 Home trips H
Step 2 Attraction Z, Zmax
=

=

=
S s
jsc
v
js
SG
jsc
ER
pot
jc
) d
jc jc
jc
jc jc
;
S s
jsc
v
js
SG
max
jsc
ER
jc
) c
S s
jsc
v
js
SG
max
jsc
ER
max
jc jc
) b
S s
jsc
v
js
SG
jsc
ER
c
f
jc
) a
Z
Z
Z
Z
Z
Z
Z
Z Z
Z
=
=
P p
epc ep epc ec
epc ep epc epc
u BP MR H
u BP MR H
H Z
jc jc
=

=

=
=
m
1 S s
sc
v
s
SG
sc
ER
c
V
c
f
n
1 j
jc
=
c
V
Z
l
l l l
=

=

=
S s
isc
v
is
SG
isc
ER
pot
ic
) d
ic ic
ic
ic ic
;
S s
isc
v
is
SG
max
isc
ER
ic
) c
S s
isc
v
is
SG
max
isc
ER
max
ic ic
) b
S s
isc
v
is
SG
isc
ER
c
f
ic
) a
Q
Q
Q
Q
Q
Q
Q
Q Q
Q
125 PTV AG
Step 1 Home trips H
Attraction Z, Zmax
e Index of a zone producing trips (origin zone)
i Index of a zone being origin of trips
j Index of a zone being destination of trips
s Index of a structural property
p Index of a person group
c Index of a demand stratum
m Number of zones in study area
MR
epc
Mobility rate of person group p per time interval
ER
isc
Production rate of structural property s per time interval
BP
ep
Number of persons per person group p
SG Structural property
u
epc
Factor of trips realized study area-internally
v
isc
Structural property factor effective for study area-internal traffic
H
epc
Home trips (expected value) of person group p
H
ec
Home trips (expected value) total
Q
ic
Production (expected value)
=
=
P p
epc ep epc ec
epc ep epc epc
u BP MR H
u BP MR H
=
m
1 e
ec
=
c
V
H
c
V
S s
sc
v
s
SG
sc
ER
S s
isc
v
is
SG
isc
ER

ic
Q
l
l l l
c
V
S s
sc
v
s
SG
sc
ER
S s
jsc
v
js
SG
jsc
ER

jc
Z
l
l l l
126 PTV AG
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 c
a
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 135).
Balancing can either be performed after trip generation or trip distribution and mode choice. It
takes place after Trip generation if the following two conditions are fulfilled.
All constraints (except those of demand stratum c
a
) are hard.
The total volume in c
a
is higher than the difference between production and attraction that
needs to be balanced.
Balancing after Trip generation takes place in three steps.
1. Calculation of total production and total attraction for all demand strata except c
a
.
;
2. Calculation of the demand to be compensated of all zones i.
;
Z
jc
Attraction (expected value)
Q
ic
max Maximum possible production
Z
jc
max Maximum possible attraction
Factor for upper or lower limit of production
Factor for upper or lower limit of attraction
Q
ic
pot Potential for origin traffic
Z
jc
pot Potential for destination traffic
V
c
Total volume (expected value)
f
c
Factor, which takes the compliance of the total constraint for the
calculation of the zones traffic volume into consideration
Q
ic
*
, Z
jc
* Ancillary parameters for balancing (see below)
ic
Q ,
ic
Q
jc
Z ,
jc
Z

= =
j
j
Z
i
i
Q V
=
a
c c
ic
Q
*
i
Q

=
a
c c
ic
Z
*
i
Z
}
*
i
Q
*
i
Z , 0 max{
*
i
Q = }
*
i
Z
*
i
Q , 0 max{
*
i
Z =
127 PTV AG
3. Correction of traffic volume in c
a
, whereby and are "preliminary" values taken
from the formulas in Table 39, Table 40 and Table 41.
The following example will illustrate the method. For simplification it is limited to five demand
strata covering all origin-destination types.
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.
Activity Person group
No. Code OD type Origin Destination Origin zone
1 HW 1 Housing Work Employees
2 HO 1 Housing Miscellaneous Inhabitants
3 WH 2 Work Housing Employees
4 OH 2 Miscellaneous Housing Inhabitants
5 OO 3 Miscellaneous Miscellaneous Inhabitants
Relevant structural potential
No. Code OD type Origin zone Destination zone
1 HW 1 Like home Jobs
2 HO 1 Like home Jobs in tertiary sector and
inhabitants
3 WH 2 Jobs Like home
4 OH 2 Jobs in tertiary sector and
inhabitants
Like home
5 OO 3 Jobs in tertiary sector and
inhabitants
Jobs in tertiary sector and
inhabitants
Zone Type Inhabitants Employees Jobs Jobs
tertiary
1 1 7.000 3.000 2.000 1.100
2 1 10.500 5.500 7.000 4.500
3 1 7.000 3.000 2.000 1.300
4 1 5.000 2.000 1.700 1.000
5 1 3.000 1.200 2.500 1.600
a
ic
Q
~
a
ic
Z
~
Q
i c
a
Q
i c
a
1
1
V
c
a
------- Q
l
*
l

Z
i
*
+ =
Z
i c
a
Z
ic
a
1
1
V
c
a
------- Z
l
*
l

Q
i
*
+ =
128 PTV AG
Depending on demand stratum and zone type the following mobility rates are applicable (trips
per person in relevant person group).
The production rates of the structural properties equally depend on demand stratum and zone
type.
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 39, Table 40 and
Table 41. For clarification the respective step of the calculation process is indicated on top of
each column.
H = Home trips
6 1 2.000 900 1.600 1.000
7 1 500 200 2.000 1.200
8 1 5.000 2.000 1.000 600
9 1 7.000 3.100 2.500 1.400
10 1 5.000 2.000 1.500 1.000
11 2 3.500 1.200 1.000 600
12 2 3.000 1.100 1.000 600
13 2 2.500 1.000 1.000 600
14 2 1.500 700 500 100
15 2 1.500 600 500 100
16 2 2.000 900 1.000 600
17 2 2.000 800 500 300
18 2 2.000 800 500 300
Zone type HW HO WH OH OO
1 0.7800 0.9000 0.6200 0.9000 0.6000
2 0.8100 0.9000 0.6400 0.9000 0.6000
Demand stratum Structural property Zone type 1 Zone type 2
HW 1.00 1.00
HO Inhabitants 0.50 0.50
Jobs in tertiary sector 0.50 0.50
WH 1.00 1.00
OH Inhabitants 0.50 0.50
OO Inhabitants 0.50 0.50
Zone Type Inhabitants Employees Jobs Jobs
tertiary
129 PTV AG
Q = Production
Z = Attraction
QP = Structural potential origin
ZP = Structural potential destination
Demand stratum HW
Home Origin Destination
Person groups or structural
property
Employee
s
Like home Jobs
Calculation step 1 2 3 4
Zone Zone Type U Q ZP Z
1 1 2.340 2.340 2.000 1.578
2 1 4.290 4.290 7.000 5.523
3 1 2.340 2.340 2.000 1.578
4 1 1.560 1.560 1.700 1.341
5 1 936 936 2.500 1.972
6 1 702 702 1.600 1.262
7 1 156 156 2.000 1.578
8 1 1.560 1.560 1.000 789
9 1 2.418 2.418 2.500 1.972
10 1 1.560 1.560 1.500 1.183
11 2 875 875 900 710
12 2 802 802 900 710
13 2 729 729 900 710
14 2 510 510 450 355
15 2 437 437 450 355
16 2 656 656 900 710
17 2 583 583 450 355
18 2 583 583 450 355
Total 23.038 23.038 29.200 23.038
Demand stratum HO
Home Origin Destinati
on
Person groups or
structural property
Inhab. Like
home
Jobs in tertiary sector and inhabitants
Calculation step 1 2 3.1 3.2 4 5
Zone Zone Type U Q ZP Inh. ZP Jobs -
tert
ZP Total Z
1 1 6.300 6.300 3.500 550 4.050 5.796
130 PTV AG
2 1 9.450 9.450 5.250 2.250 7.500 10.733
3 1 6.300 6.300 3.500 650 4.150 5.939
4 1 4.500 4.500 2.500 500 3.000 4.293
5 1 2.700 2.700 1.500 800 2.300 3.292
6 1 1.800 1.800 1000 500 1.500 2.147
7 1 450 450 250 600 850 1.216
8 1 4.500 4.500 2.500 300 2.800 4.007
9 1 6.300 6.300 3.500 700 4.200 6.011
10 1 4.500 4.500 2.500 500 3.000 4.293
11 2 2.835 2.835 1.575 270 1.845 2.640
12 2 2.430 2.430 1.350 270 1.620 2.318
13 2 2.025 2.025 1.125 270 1.395 1.996
14 2 1.215 1.251 675 45 720 1.030
15 2 1.215 1.251 675 45 720 1.030
16 2 1.620 1.620 900 270 1.170 1.674
17 2 1.620 1.620 900 135 1.035 1.481
18 2 1.620 1.620 900 135 1.035 1.481
Total 61.380 61.380 34.100 8.790 42,890 61.380
Demand stratum WH
Home Destination Origin
property
Like home Jobs
Calculation step 1 2 3 4
Zone Zone Type U Z QP Q
1 1 1.860 1.860 2.000 1.253
2 1 3.410 3.410 7.000 4.384
3 1 1.860 1.860 2.000 1.253
4 1 1.240 1.240 1.700 1.065
5 1 744 744 2.500 1.566
6 1 558 558 1.600 1.002
7 1 124 124 2.000 1.253
8 1 1.240 1.240 1.000 626
9 1 1.922 1.922 2.500 1.566
10 1 1.240 1.240 1.500 939
11 2 691 691 900 564
12 2 634 634 900 564
13 2 576 576 900 564
131 PTV AG
14 2 403 403 450 282
15 2 346 346 450 282
16 2 518 518 900 564
17 2 461 461 450 282
18 2 461 461 450 282
Total 18.288 18.288 29.200 18.288
Demand stratum OH
Home Destinati
on
Origin
Person groups or
structural property
Inhab. Like
home
Calculation step 1 2 3.1 3.2 4 5
Zone Zone Type U Z QP Inh. QP Jobs
tert
QP Total Q
1 1 6.300 6.300 3.500 550 4.050 5.796
2 1 9.450 9.450 5.250 2.250 7.500 10.733
3 1 6.300 6.300 3.500 650 4.150 5.939
4 1 4.500 4.500 2.500 500 3.000 4.293
5 1 2.700 2.700 1.500 800 2.300 3.292
6 1 1.800 1.800 1.000 500 1.500 2.147
7 1 450 450 250 600 850 1.216
8 1 4.500 4.500 2.500 300 2.800 4.007
9 1 6.300 6.300 3.500 700 4.200 6.011
10 1 4.500 4.500 2.500 500 3.000 4.293
11 2 2.835 2.835 1.575 270 1.845 2.640
12 2 2.430 2.430 1.350 270 1.620 2.318
13 2 2.025 2.025 1.125 270 1.395 1.996
14 2 1.215 1.215 675 45 720 1.030
15 2 1.215 1.215 675 45 720 1.030
16 2 1.620 1.620 900 270 1.170 1.674
17 2 1.620 1.620 900 135 1.035 1.481
18 2 1.620 1.620 900 135 1.035 1.481
Total 61.380 61.380 34.100 8.790 42,890 61.380
Demand stratum OO
Home Origin
132 PTV AG
property
Calculation step 2.1 2.2 2.3 2
Zone Zone Type U QP Inh. QP Jobs
tert
QP Total Q
1 1 4.200 3.500 550 4.050 3.864
2 1 6.300 5.250 2.250 7.500 7.156
3 1 4.200 3.500 650 4.150 3.959
4 1 3.000 2.500 500 3.000 2.862
5 1 1.800 1.500 800 2.300 2.194
6 1 1.200 1.000 500 1.500 1.431
7 1 300 250 600 850 811
8 1 3.000 2.500 300 2.800 2.671
9 1 4.200 3.500 700 4.200 4.007
10 1 3.000 2.500 500 3.000 2.862
11 2 1.890 1.575 270 1.845 1.760
12 2 1.620 1.350 270 1.620 1.546
13 2 1.350 1.125 270 1.395 1.331
14 2 810 675 45 720 687
15 2 810 675 45 720 687
16 2 1.080 900 270 1.170 1.116
17 2 1.080 900 135 1.035 987
18 2 1.080 900 135 1.035 987
Total 40.920 34.100 8.790 42,890 40.920
Demand stratum OO
Destination
property
Calculation step 3.1 3.2 3.3 3
Zone Zone Type ZP Inh. ZP Jobs - tert ZP Total Z
1 1 3.500 550 4.050 3.864
2 1 5.250 2.250 7.500 7.156
3 1 3.500 650 4.150 3.959
4 1 2.500 500 3.000 2.862
5 1 1.500 800 2.300 2.194
6 1 1.000 500 1.500 1.431
7 1 250 600 850 811
133 PTV AG
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.

8 1 2.500 300 2.800 2.671
9 1 3.500 700 4.200 4.007
10 1 2.500 500 3.000 2.862
11 2 1.575 270 1.845 1.760
12 2 1.350 270 1.620 1.546
13 2 1.125 270 1.395 1.331
14 2 675 45 720 687
15 2 675 45 720 687
16 2 900 270 1.170 1.116
17 2 900 135 1.035 987
18 2 900 135 1.035 987
Total 34.100 8.790 42,890 40.920
Note: Note that neither total origin and nor total destination traffic of this demand stratum
change.
Total HW+HO+WH+OH Differences
Zone Q Z Q Z
1 16.800 14.422 2.378 0
2 26.600 31.373 0 4.773
3 16.800 14.709 2.091 0
4 11.800 10.993 807 0
5 7.080 10.121 0 3.041
6 4.860 6.558 0 1.698
7 1.180 5.263 0 4.083
8 11.800 9.429 2.371 0
9 16.940 15.559 1.381 0
10 11.800 10.710 1.090 0
11 7.236 6.555 681 0
12 6.296 5.911 385 0
13 5.355 5.267 88 0
14 3.344 2.698 646 0
15 3.213 2.698 515 0
16 4.415 4.623 0 208
134 PTV AG
The results of operation EVA trip generation are stored in zone attributes.
17 4.284 3.599 685 0
18 4.284 3.599 685 0
Total 164.086 164.086 13.804 13.804
OO before balancing OO after balancing
Zone Q Z Q Z
1 3.864 3.864 2.561 4.938
2 7.156 7.156 9.515 4.742
3 3.959 3.959 2.624 4.715
4 2.862 2.862 1.897 2.704
5 2.194 2.194 4.495 1.454
6 1.431 1.431 2.646 948
7 811 811 4.621 537
8 2.671 2.671 1.770 4,141
9 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 1.116 1.116 948 740
17 987 987 654 1.339
18 987 987 654 1.339
Total 40.920 40.920 40.920 40.920
HomeTrips Demand stratum Home trips for demand stratum
Range: floating point number
ProductionsTarget Demand stratum Productions for demand stratum, before taking account of
constraints
AttractionsTarget Demand stratum Same for attractions
135 PTV AG
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 W
ij
.
Hereby T
ij
is the number of trips from i to j, W
ij
is the cost function for the trip from i to j, Q
i
is
the production of zone i and Z
j
is the attraction of zone j. The factors fq
i
, fz
j
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.
Here, index k is the mode (means of transport) and W
ijk
assesses the costs for the trip from i to
j by mode 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 VK
k
of trips with
mode k is required. There are two possibilities.
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.
Attractions Demand stratum Same for attractions
n) 1,..., = j m; 1,..., = i (
j
z f
i
q f
ij
W
ij
T =
j
Z =
m
1 i
ij
T
j
z f
i
q f
m
1 = i
ij
W
i
Q =
n
1 j
ij
T
j
z f
i
q f
n
1 = j
ij
W

=
=
=
=
p) 1,..., = k n; 1,..., = j m; 1,..., = i (
k
a f
j
z f
i
q f
ijk
W
ijk
T =
k
VK =
m
1 i
n
1 j
ijk
T
m
1 = i
n
1 j
k
a f
j
z f
i
q f
ijk
W
j
Z =
m
1 i
p
1 k
ijk
T
m
1 = i
p
1 k
k
a f
j
z f
i
q f
ijk
W
i
Q =
n
1 j
p
1 k
ijk
T
n
1 = j
p
1 k
k
a f
j
z f
i
q f
ijk
W

= =
=
=

= =
=
=

= =
=
=

136 PTV AG
If EVA trip distribution and mode choice for the analysis case is performed, which means
without having run a precalculation 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 re-
used. 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
with
taking account of the constraints. The solution is the trilinear equation system previously
determined.
The parameter I represents the information gained through the replacement of distribution w
ijk
(solely determined by the weighting matrix) by distribution p
ijk
(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 c
aijk
is the assessment of type a of a trip from i to j by mode k, then the following applies:
whereby
here M
ijk
stands for the availability of mode k on OD pairs (i,j) and C
ijk
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.
Minimum
ijk
w
ijk
p
ld
ijk
ijk
p = I
rsl
rsl
W
ijk
W
=
ijk
w ;
V
ijk
T
=
ijk
p
W
ij k
M
ij k
C
i jk
P
i jk
=
P
ijk
f
a'
c
a' ij k
( ) f
a''
c
a'' ij k
( ) [ ] f
a'''
c
a''' ij k
( ) f
a
c
aijk
( )
a A
=
137 PTV AG
M
ijk
and C
ijk
are defined independently from the demand stratum as follows:
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 M
ijk
. In all
other cases, this assessment type has the same effect as a user-defined one.
You can use different function types as f
a
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 157), too.
OD type Definition of M
ijk
and C
ijk
Type 1 M
ijk
= m
k
(i) for all j, i.e. value of zone attribute m
k
set for source zone i
C
ijk
= c
k
(j) for all i, i.e. value of zone attribute c
k
set for destination zone j
Type 2 M
ijk
= m
k
(j) for all i, i.e. value of zone attribute m
k
set for destination zone j
C
ijk
= c
k
(i) for all j, i.e. value of zone attribute c
k
set for source zone i
Type 3 without accounting for home zone
M
ijk
= 1 for all i,j,k
C
ijk
= c
k
(i) c
k
(j)
including accounting for home zone
C
ijk
= c
k
(i) c
k
(j)
whereby h
n
stands for the home trips of zone n, represents the product matrix from the
top, but the predefined assessment type External weighting matrix is not included in the
product:
EVA1
where
EVA2
Schiller
M
ij k
m
k
n ( )
n
h
n
P
nik
P
j nk

h
n
n
---------------------------------------------------------------- =
P
ijk
f
a'
c
a' ij k
( ) f
a''
c
a'' ij k
( ) [ ] f
a
c
ai jk
( )
a A
=
( )
) x (
) x 1 ( x f

+ = ) cx b exp( 1
a
) x (
+
=
( )
a
b
c
x
1 x f

+ =
( )
a
b
x
1
1
x f
+
=
138 PTV AG
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 52 some of them have
been illustrated. Their parameters can be interpreted geometrically.
The related elasticity functions are determined by
The elasticity function is defined as the
limit of the quotient of the relative variation of the function f and the relative variation of the
impedance w.
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.
Logit
Kirchhoff
BoxCox
Box-Tukey
where
Combined
TModel
None f(x) = x
a Parameter marking the horizontal asymptote of function (w), thus influencing the degree of
approximation of the function f(w) to the w asymptote.
b Parameter influencing the degree of approximation to the horizontal F(w)=1 in the proximity
of low assessment
c Parameter influencing the slope of the function f(w)
b/c Position of the inflection point WP=F/G of function (w) where the function (w) features the
greatest rise or the highest "impedance sensitivity"
( )
( ) x c
e x f

=
( )
c
x x f =
( )

=
b
1 x
c
e x f
b
( )
( )
x c
e x f

=

= +
>
+
=
0 b ), 1 x ln(
0 b , b / 1
b
) 1 x (
( )
( ) x c
e
b
x a x f

=
( )
a
x c
b
x
1
x f
+
=
.
) w G F exp( 1
) w G F exp( G
) w 1 ln(
w 1
1
) w G F exp( 1
w E
) w (
f
+

+ +
+
+

=
) w ( f
w
dw
) w ( df
w
h
) w ( f
) w ( f ) h w ( f
0 h
lim ) w (
f
=
+
=
139 PTV AG
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).
Illustration 52: EVA1 function in dependence of impedance w
The EVA2 function has the following parameters.
a, b ... 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).
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
1,1
0 10 20 30 40 50 60 70 80 90 100110120
f(w)
f1(E=2; F=5; G=0,24) f2(E=4; F=6; G=0,08)
f3(E=0,6; F=6; G=0,06) f4(E=20; F=12;G=0,08)
-30
-25
-20
-15
-10
-5
0
0 10 20 30 40 50 60 70 80 90 100110120
eps(w)
140 PTV AG
The illustration 53 shows the influence of a and b on the progression of the function. The two
other parameters are both kept constant.
Illustration 53: 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, too. Due to the lower number of parameters the calibration effort
is by far lower than for EVA2.
c ... Scale parameter for impedance values.
applies.
2 / 1 ) c ( f =
EVA2 Function (a variable)
0,0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1,0
05
1
0
1
5
2
0
2
5
3
0
3
5
4
0
4
5
5
0
5
5
6
0
6
5
7
0
7
5
8
0
8
5
9
0
9
5
1
0
0
Assessment x
U
t
i
l
i
t
y

f
(
x
)
a = 0
a = 1
a = 2
a = 3
EVA2 Function (b variable)
0,0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1,0
05
1
0
1
5
2
0
2
5
3
0
3
5
4
0
4
5
5
0
5
5
6
0
6
5
7
0
7
5
8
0
8
5
9
0
9
5
1
0
0
Assessment x
U
t
i
l
i
t
y

f
(
x
)
b = 1
b = 3
b = 5
b = 7
141 PTV AG
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
during iteration step p (p=1,2,), the system calculates approximations for fq
i
, fz
j
and fa
k
as
follows.
(i = 1,,m)
(j = 1,,n)
(k = 1,,K).
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 T
ijk
that matches the constraints and for which T
ijk
= 0 is true for all pairs (i,j) with W
ij
=
0. This condition is fulfilled when W
ij
> 0 is true for all (i,j), since then the matrix with
elements (the matrix that corresponds to the random model) can be chosen
as a 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.
Problem solution 2: The trilinear Multi method
Another possibility to solve the problem is to set separate fixed point equations for the vectors
fq
i
, fz
j
and fa
k
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 173). Approximations for the solution of the trilinear problem
then can be determined according to the following iteration rule.
( ) ( ) ( ) ( ) K ,..., 1 k ; n ,..., 1 j ; m ,..., 1 i 1 1
k
fa 1
j
fz 1
i
fq = = = = = =
( )
( ) ( )

= =

= +
n
1 j
K
1 k
p
k
fa p
j
fz
ijk
W
i
Q
1 p
i
fq
( )
( ) ( )

= =
+
= +
m
1 i
K
1 k
p
k
fa 1 p
i
fq
ijk
W
j
Z
1 p
j
fz
( )
( ) ( )

= =
+ +
= +
m
1 i
n
1 j
1 p
j
fz 1 p
i
fq
ijk
W
k
VK
1 p
k
fa
V
k
fa
j
Z
i
Q
ijk
T

=
( ) ( ) K ,..., 1 k ; n ,..., 1 j ; m ,..., 1 i
ijk
W 1
ijk
T = = = =
142 PTV AG
(p = 1, 2,)
with
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
( ) ( )
( )
( )
( )
( )
( )
( )
( )

= = =
= +
m
1 r
n
1 s
K
1 t
p
rst
T
V
p
k
aa
p
k
a
p
j
zz
p
j
z
p
i
qq
p
i
q
p
ijk
T 1 p
ijk
T
( )
( )

= =
=
n
1 s
K
1 t
p
ist
T
i
Q
p
i
q
( )
( ) ( ) ( ) [ ]
( )

= =
= =
+
=
n
1 s
K
1 t
p
ist
T 2
n
1 s
K
1 t
p
t
a p
s
z p
ist
T
p
i
qq
( )
( )

= =
=
m
1 r
K
1 t
p
rjt
T
j
Z
p
j
z
( )
( ) ( ) ( ) [ ]
( )

= =
= =
+
=
m
1 r
K
1 t
p
rjt
T 2
m
1 r
K
1 t
p
t
a p
r
q p
rjt
T
p
j
zz
( )
( )

= =
=
m
1 r
n
1 s
p
rsk
T
k
VK
p
k
a
( )
( ) ( ) ( ) [ ]
( )

= =
= =
+
=
m
1 r
n
1 s
p
rsk
T 2
m
1 r
n
1 s
p
s
z p
r
q p
rsk
T
p
k
aa
143 PTV AG
calculated by Trip generation constitutes an upper limit. Thus, the trilinear problem changes
into
under the constraints
The procedure for multi-problem solving is mostly identical with the constraint equation
method, except that z
j
(p) and zz
j
(p) are calculated differently.
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.

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 118), 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.
Note: Differences in marginal sums can only be balanced after trip generation if all demand
strata feature hard constraints.
k
fa
j
fz
i
fq
ijk
W
ijk
T =
=
i j
k
VK
ijk
T
i k
max
j
Z
ijk
T
j k
i
Q
ijk
T
( )
( ) ( )
( )
( )
( )
( ) ( ) ( ) ( )
( )

=
=
p
j
Z 2
i k
p
k
a p
i
q p
ijk
T
;
1 p
j
fz
1
min p
j
zz
1 0
j
fz ;
p
j
Z
max
j
Z
;
1 p
j
fz
1
min p
j
z
144 PTV AG
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 W
ijk
(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
stratum and mode. You can also display the balance factors for productions and attractions fq
i
and fz
j
, that result from the equation system. The balance factor for mode choice fa
k
is
calculated for analysis, but not for forecast scenarios.
3.2.3 Activity chain based model (VISEM)
VISEM 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. VISEM
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 VISEM, 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 VISEM: Calculation on the basis of groups with homogeneous behavior and
activity chains.
3.2.3.1 VISEM Data model
The VISEM 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 106).
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 VISEM.
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 106).
Some changes in the demand objects, which are especially necessary for the VISEM model,
are described below.

Changes to activities in the VISEM 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.
Note: In a VISUM-VISEM 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.
145 PTV AG
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 double-sided coupled trip distribution is calculated for each
activity transfer.
This results in the following new attributes:
Changes to activity pairs in the VISEM model
VISEM 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:
Changes to person groups in the VISEM model
The result matrix of the VISEM calculations are saved per person group. In addition to the total
result matrix, a demand matrix is calculated per destination activity (as a result of trip
distribution) and per mode (as a result of mode choice) for each person group.
This results in the following new attributes:
Activity Structural property Structural property value = target potential
Work ('W') Jobs Number of 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 ('B') University places Number of university places
Type of demand
object
Attribute and range of values Meaning
Activity StructuralPropertiesCodes
Reference to the activity relevant structural
propert(ies)
Activity CouplingDestination
Range: bool {0, 1}
Destination-sided coupling during trip distribution
(yes / no). Home activity always =1.
Activity ConstraintMinFactorDest /
ConstraintMaxFactorDest
Factor for the lower or upper limit of the
constraint on destination side, if
CouplingDestination = 1.
For home activity, both factors are always = 1.0.
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 105)
Person group Reference to a standard
time series, which has to be
proportional
146 PTV AG
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.
Type of demand
object
Attribute and range of values Subattribute Meaning
Person group DistribMatrixNumber
Range: set of demand matrices
- Reference to total result
matrix of trip distribution
Person group Activity matrix number
Activity Reference to trip purpose-
specific result matrix of trip
distribution
Person group Mode choice matrix number
Mode Reference to result matrix of
mode choice
E+c E-c NE+c NE-c Appren Stud Pas PPup Child
HWH 74.25 62.60 8.18 2.82 33.48 11.08 1.92 0.0 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
Table 42: List of the activity chains: mobility rates per person group in %
147 PTV AG
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. Trip generation, i.e. determining the absolute number of activity chains and thus
trips that starting from any of the individual zones. In VISEM trip generation is calculated by
multiplying the inhabitants of each person group with the probabilities of all activity chains.
This means that in VISEM trip generation (the number of trips created with each activity in the
activity chain) is determined together with the number of inhabitants and person group
distribution. The result is saved in the zone attribute Home trips for each demand strata.
Example of trip distribution in VISEM
2000 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 2000 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 2000 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 VISEM Trip distribution/Mode choice combined
For each changeover of an activity chain, both a total demand matrix and a demand matrix per
mode are calculated. For each person group, the results are output in aggregated format,
separated by destination activity and mode.
Trip distribution: route links through destination choice according to activities
Depending on the destination activity of a trip, VISEM 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.
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
E+c E-c NE+c NE-c Appren Stud Pas PPup Child
Table 42: List of the activity chains: mobility rates per person group in %
148 PTV AG
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 156)
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.
With the destination choice model, VISEM needs a target potential Z
j
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 "VISEM Data model" on
page 144) that belongs to the activity.
The utility function f(uij
)
is pivotal in the destination choice model. It specifies the probability P
ij
with which one of the zones j is selected as destination zone (from all destination alternatives)
of origin zone i.
where
whereby u
ij
describes the utility relation ij and the utility function f(ui
j)
(e.g. of the type Logit) can
consequently be defined as . All other evaluation functions of the EVA demand
model can also be used as utility functions in VISEM (see "EVA Trip Distribution and Mode
Choice" on page 135).
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 u
ij
has no influence on the choice of destination. The larger c is, the larger is the impact
of utility u
ij
on the choice of the destination (see "Gravity model calculation" on page 157).
You need to define function parameters for each combination of person groups and destination
activity.
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 distribution in VISEM" on page 147).
F
ij
Number of trips from zone i to zone j
Q
i
Productions in zone i
P
ij
Choice probability of destination j for origin zone i
Z
j
Target potential in zone j
k Index of zones (with k = the smallest zone number and B = the number of zones)
F
ij
Q
i
P
i j
=
P
ij
Z
j
f u
ij
( )
Z
k
f u
ik
( )
k 1 =
B
------------------------------------------ =
f u
ij
( ) e
cu
i j
=
149 PTV AG
Example of trip generation
A Logit utility function ( 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. VISEM distributes these 93.4 trips to the destination zones,
according to the previously described destination choice 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 Z
1
= 0, Z
2
= 100, Z
3
= 0. The VISEM trip distribution formulas produce the
following results P
11
= 0, P
12
= 1 and P
13
= 0, and therefore F
11
= 0, F
12
= 93.4 and F
13
= 0.
Zone 2 is therefore the destination of all trips of zone 1.

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: Z
1
= 0, Z
2
= 50, Z
3
= 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 u
22
= 2 and u
23
= 1. The VISEM trip
distribution formulas produce the following results: P
21
= 0, P
22
0.6 and P
23
0.4, and
therefore F
21
= 0, F
22
56.0 and F
23
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.
Matrix F
1
for the first activity transfer (Destination activity W)
Matrix F
2
for the second activity transfer (Destination activity O)
Note: The definition of the utility function in this case does not influence the calculation.
Zone 93.4 1 2 3
93.4 Total 0 93.4 0
1 93.4 0 93.4 0
2 0 0 0 0
3 0 0 0 0
Zone 93.4 1 2 3
93.4 Total 0 56.0 37.4
1 0 0 0 0
2 93.4 0 56.0 37.4
f u
ij
( ) e
cu
i j
=
150 PTV AG
Matrix F
3
for the third activity transfer (Destination activity H)
Summed up, the following total demand matrix applies F
G
.
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-2-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

VISEM 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.
3 0 0 0 0
Zone 93.4 1 2 3
93.4 Total 93.4 0 0
1 0 0 0 0
2 56.0 56.0 0 0
3 37.4 37.4 0 0
Zone 280.2 1 2 3
280.2 Total 93.4 149.4 37.4
1 93.4 0 93.4 0
2 149.4 56.0 56.0 37.4
3 37.4 37.4 0 0
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.
Zone 93.4 1 2 3
93.4 Total 0 56.0 37.4
151 PTV AG

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 about 6000 jobs in the study area, with 1000 jobs, the zone has
a relative destination potential of 1000/6000 = 1/6 for the activity Work. If a demand stratum
has a total of 3000 home trips, the absolute destination potential of the zone for this demand
stratum, nominated on the total home trips = 3000 1/6 = 500. This absolute value is used in
the doubly coupled gravity model, as constraint on destination side for this demand stratum
(see "Gravity model calculation" on page 157).
The trip distribution results are saved in aggregated format in a total demand matrix per person
group and additionally in a matrix per destination activity.
Mode choice: discrete distribution model
The VISEM 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 non-
exchangeable 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.
where
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. So for example, destination potential jobs = 1000 in a zone does not necessarily
mean, that VISEM leads 1000 trips with destination activity to this zone. In fact, the
destination traffic depends on the product of destination potential and utility function value in
relation to the other zones.
i, j Indices of the traffic zones
m Index of modes (M = total number)
P
m
ij
Probability of selecting mode m for trip from i to j
u
m
ij

Utility when choosing mode m for trip from i to j
P
ij
m
f u
ij
m
( )
f u
ij
k
( )
k 1 =
M
------------------------------ =
152 PTV AG
can e.g. be a Logit utility function and thus be defined as . As an
alternative, all available types of evaluation functions can be used from the EVA demand
method as a utility function for the VISEM mode choice (see "EVA Trip Distribution and Mode
Choice" on page 135).
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.
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)
VISEM 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 149) 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
modes X and W in short is also designated with A. A Logit utility function ( with parameter c =
0.4) is used again to represent the changeovers from and to the individual
activities. The utility matrices u
m
for each mode m are provided by
u
P
u
O
Zone 1 2 3
1 3 3 3
2 3 3 3
3 3 3 3
Zone 1 2 3
1 2 1 1
2 1 2 2
3 1 2 2
f u
ij
m
( ) f u
ij
m
( ) e
cu
ij
m
=
f u
ij
m
( ) e
cu
ij
m
=
153 PTV AG
u
F
After analyzing the formula above, the following probability matrices apply.
P
P
P
O
P
F
P
A
= P
O
+ P
F
Interesting are also the probabilities for modes X and W within the exchangeable modes.
PA
O
= P
O
/ P
A
Zone 1 2 3
1 1 1 1
2 1 1 1
3 1 1 1
Zone 1 2 3
1 0.472 0.526 0.526
2 0.526 0.472 0.472
3 0.526 0.472 0.472
Zone 1 2 3
1 0.316 0.237 0.237
2 0.237 0.316 0.316
3 0.237 0.316 0.316
Zone 1 2 3
1 0.212 0.237 0.237
2 0.237 0.212 0.212
3 0.237 0.212 0.212
Zone 1 2 3
1 0.528 0.474 0.474
2 0.474 0.528 0.528
3 0.474 0.528 0.528
Zone 1 2 3
1 0.598 0.5 0.5
2 0.5 0.598 0.598
154 PTV AG
PA
F
= P
F
/ P
A
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 P
P
with the total demand matrix F
1
of the first
transfer.
Total demand matrix F
1
for the first activity transfer (Destination activity W)
Matrix F
P1
for mode C and the first activity transfer (Destination activity W)
With the next activity changeover, these 49.12 trips will be distributed across zones 2 and 3
according to the distribution probabilities (P
22
= 0.6 or P
23
= 0.4).
Matrix F
P2
for mode C and the second activity transfer (Destination activity O)
Finally, the trips have to end back at the last activity transfer in their origin zone 1.
3 0.5 0.598 0.598
Zone 1 2 3
1 0.402 0.5 0.5
2 0.5 0.402 0.402
3 0.5 0.402 0.402
Zone 93.4 1 2 3
93.4 Total 0 93.4 0
1 93.4 0 93.4 0
2 0 0 0 0
3 0 0 0 0
Zone 49.12 1 2 3
49.12 Total 0 49.12 0
1 49.12 0 49.12 0
2 0 0 0 0
3 0 0 0 0
Zone 49.12 1 2 3
49.12 Total 0 29.47 19.65
1 0 0 0 0
2 49.12 0 29.47 19.65
3 10 0 0 0
Zone 1 2 3
155 PTV AG
Matrix F
P3
for mode C and the third activity transfer (Destination activity H)
Summed up, the following Car total demand matrix applies: F
PG
To determine the total demand matrix for non-exchangeable modes, this Car matrix is
subtracted from the total demand matrix F
G
(from trip distribution).
F
G
The difference first results in the total demand matrix for all non-exchangeable modes.
F
A
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 PA
O
and PA
F
.
Zone 49.12 1 2 3
49.12 Total 49.12 0 0
1 0 0 0 0
2 29.47 29.47 0 0
3 19.65 19.65 0 0
Zone 147.36 1 2 3
147.36 Total 49.12 88.59 19.65
1 49.12 0 49.12 0
2 88.59 29.47 29.47 19.65
3 19.65 19.65 0 0
Zone 280.2 1 2 3
280.2 Total 93.4 149.4 37.4
1 93.4 0 93.4 0
2 149.4 56.0 56.0 37.4
3 37.4 37.4 0 0
Zone 132.84 1 2 3
132.84 Total 44.28 70.81 17.75
1 44.28 0 44.28 0
2 70.81 26.53 26.53 17.75
3 17.75 17.75 0 0
156 PTV AG
PuT total demand matrix F
O
Walk total demand matrix F
F
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 aggregated form in a demand matrix per person group
and mode.
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.
where
2.
where
The KALIBRI function adjusts these utility functions to a given trip length distribution.
Then the Trip distribution function calculates the traffic flow F
ij
(from zone i to zone j) with the
aid of the gravity model and known data, namely the source traffic Q
i
(of zone i), destination
Zone 70.75 1 2 3
70.75 Total 22.14 38.00 10.61
1 22.14 0 22.14 0
2 39.74 13.27 15.86 10.61
3 8.87 8.87 0 0
Zone 62.09 1 2 3
62.09 Total 22.14 32.81 7.14
1 22.14 0 22.14 0
2 31.07 13.26 10.67 7.14
3 8.88 8.88 0 0
U
ij
Value of the utility (for example distance or travel time) between zone i and zone j
a,b,c Parameters to be estimated
U
ij
Value of the utility (for example distance or travel time) between zone i and zone j
a,c Parameters to be estimated
( )
ij
U c
e
b
ij
U a
ij
U f

=
( )
ij
U c
e a
ij
U f

=
157 PTV AG
traffic Z
j
(of zone j) and the parameters a, b, c (or a, c) specified here (see "Gravity model
calculation" on page 157).
The KALIBRI function provides two options that allow you to estimate the parameters for the
gravity model.
production distribution
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)
or
(3)
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 112 and "VISEM Trip distribution/Mode choice combined" on page 147).
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 F
ij
, 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).
( )
ij
U c
ij
U ln b a ln
ij
U f ln + + =
( )
ij
U c a ln
ij
U f ln + =
General form of the distribution formula
where
Logit

Kirchhoff
F
ij
k
ij
Q
i
Z
j
f U
ij
( ) =
f U
i j
( ) e
cU
i j
=
f U
i j
( ) U
ij
c
=
158 PTV AG
The distribution formula is referred to an attraction or utility function, with the following
parameters.
Determining the scaling factor k
ij
and formulating the utility function f(Ui
j)
are essential for
various modifications and extensions.
The scaling factor k
ij
must be chosen so that the boundary conditions of the distribution models
(4.1)
and
(4.2)
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 k
ij
only depends on i, so we write .
For logical reasons, coupling for production requires that there are as many free parameters as
there are zones.
This leads to the formulation
with the following secondary conditions for zone i.
BoxCox
Combined
TModel
U
ij
Value for the utility between zones, for example distance or travel time from zone i to zone j.
Q
i
Origin zone i
Z
j
Destination zone j
k
ij
Scaling factor (attractiveness factor) for OD pair zone i to zone j.
n Number of zones
f U
i j
( ) e
c
U
ij
b
1
b
------------------
=
f U
i j
( ) a U
ij
b
e
cU
i j
=
f U
i j
( )
1
U
ij
b
cU
ij
a
+
----------------------------- =
F
i j
j 1 =
n
Q
i
=
F
i j
i 1 =
n
Z
j
=
k
i
F
ij
k
i
Q
i
Z
j
f U
ij
( ) =
F
i j
j 1 =
n
Q
i
=
159 PTV AG
From the n secondary conditions, all can thus be determined by substitution in the
distribution function:
This results in
for Q
i
0
This produces a destination choice model of production distribution.
for all i, j
The destination choice model of attraction distribution is derived analogously.
for all i, j with
The adjustment of the model to reality (calibration) by variation of the free parameters is very
important.
Since the input parameters Q
i
and Z
j
have been specified, the only free parameters that remain
besides the scaling factors ( and ) are the parameters of the utility function f(Uij
)
.
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 and as well
as = 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 174).
The general form of the utility function f(Uij
)
is
It is depicted for several b and c parameters in the following two figures.
k
i
Q
i
F
ij
j 1 =
n
k
i
Q
i
Z
j
f U
ij
( )
j 1 =
n
k
i
Q
i
Z
j
f U
ij
( )
j 1 =
n
= = =
k
i
1
Z
j'
f U
i j'
( )
j' 1 =
n
------------------------------------------- =
F
ij
Q
i
Z
j
f U
i j
( )
Z
j'
f U
ij'
( )
j' 1 =
n
------------------------------------------- =
F
ij
Q
i
Z
j
f U
ij
( )
Q
i'
f U
i' j
( )
i' 1 =
n
-------------------------------------------- = k
j
1
Q
i'
f U
i' j
( )
i' 1 =
n
-------------------------------------------- =
k
i
k
j
k
i
k
j
k
i
k
j
f U
i j
( ) a U
ij
b
e
cU
i j
=
160 PTV AG
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.
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.
Attractiveness with a = 1 and b = 0
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
0 2 4 6 8 10 12 14 16 18 20
Utility between zone i and zone j
f
(
U
i
j
)
c = -0,01
c = -0,1
c = -0,3
c = -0,5
c = -1
Uij
Attractiveness with a = 1 and c = -0,1
0
0,2
0,4
0,6
0,8
1
1,2
1,4
1,6
1,8
2
0 5 10 15 20 25 30 35 40
Utility between zone i and zone j
f
(
U
i
j
)
b = 0,1
b = 0,3
b = 0,5
b = 0,7
Uij
161 PTV AG
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
or
whereby k
i
or k
j
are attractiveness factors of the i. or j. zones.
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,
with k
i
being the attractiveness factor of the i. zone.
Input file Utility
* Zone number s
1 2 3 4
* 2. 66 1. 75 1. 99 1. 50
* 1 2. 08
1. 00 0. 50 0. 33 0. 25
* 2 2. 33
0. 33 0. 50 1. 00 0. 50
* 3 1. 41
0. 33 0. 25 0. 33 0. 50
* 4 2. 08
1. 00 0. 50 0. 33 0. 25
* 7. 90
Input data for calculation without balancing
*Zone Pr oduct i on At t r act i on Fact or Ext er nal
1 10. 0000 50. 0000 0. 50000000 0
2 20. 0000 10. 0000 1. 00000000 0
3 30. 0000 20. 0000 1. 00000000 0
4 40. 0000 20. 0000 1. 00000000 1
The parameters are set as follows:
Combined utility function (exponential)
Parameter a = 1, b = 0.5 and c = -1
Singly-constrained for production without balancing
Result matrix
* Zone number s
1 2 3 4
* 36. 76 15. 91 30. 79 16. 55
* 1 10. 00
3. 11 1. 45 2. 80 2. 64
* 2 20. 01
6. 76 2. 81 4. 82 5. 62
* 3 30. 00
9. 97 3. 76 7. 98 8. 29
* 4 40. 00
Z
j
j 1 =
n
Q
i
k
i
i 1 =
n
= Q
i
i 1 =
n
Z
j
k
j
j 1 =
n
=
Q
i
i 1 =
n
Z'
j
j 1 =
n
=
Z
j
j 1 =
n
Q
i
k
i
i 1 =
n
+
2
-----------------------------------------------------------
162 PTV AG
16. 92 7. 89 15. 19 0. 00
* 100. 01
Input data for calculating balancing and scaling according to average value
*Zone Pr oduct i on At t r act i on Fact or Ext er nal
1 10. 0000 50. 0000 0. 50000000 0
2 20. 0000 10. 0000 1. 00000000 0
3 30. 0000 20. 0000 0. 30000000 0
4 40. 0000 20. 0000 1. 00000000 1
Direction of the distribution according to the production distribution with boundary sum
balancing enforced by the multi procedure.
Scaling according to mean value of both sums
Max. number of iterations = 10, Quality factor = 3
Result matrix
* Zone number s
1 2 3 4
* 32. 99 13. 19 7. 92 26. 39
* 1 8. 04
2. 22 0. 94 0. 56 4. 32
* 2 16. 10
4. 62 1. 74 0. 93 8. 81
* 3 24. 16
6. 95 2. 38 1. 57 13. 26
* 4 32. 19
19. 20 8. 13 4. 86 0. 00
* 80. 49
Example 2: Gravity model singly-constrained for production, with balancing
Input file Utility
* Zone number s
1 2 3 4 5
* 166, 183 107, 560 88, 972 134, 710 155, 725
* 1 165, 571
0, 001 22, 700 35, 183 50, 387 57, 300
* 2 107, 414
22, 700 0, 001 15, 991 31, 017 37, 705
* 3 90, 008
35, 926 16, 284 0, 001 15, 153 22, 644
* 4 134, 633
50, 387 31, 017 15, 153 0, 001 38, 075
* 5 155, 524
57, 169 37, 558 22, 644 38, 152 0, 001
* 653, 150
Input data
*Zone Pr oduct i on At t r act i on
1 18990. 0 18990. 0
2 4960. 0 4960. 0
3 7110. 0 7110. 0
4 16080. 0 16080. 0
5 2300. 0 2300. 0
Location factor and zone property external are not specified. Default values are used.
163 PTV AG
Scaling according to the production total
Result matrix
* Zone number s
1 2 3 4 5
* 18990. 000 4959. 951 7109. 758 16080. 290 2300. 000
* 1 18990. 000
18990. 000 0. 000 0. 000 0. 000 0. 000
* 2 4959. 999
0. 000 4959. 897 0. 102 0. 000 0. 000
* 3 7110. 000
0. 000 0. 054 7109. 426 0. 520 0. 000
* 4 16080. 000
0. 000 0. 000 0. 230 16079. 770 0. 000
* 5 2300. 000
0. 000 0. 000 0. 000 0. 000 2300. 000
* 49439. 999
Example 3: Gravity model singly-constrained for attraction, without balancing
Input file impedances
* Zone number s
1 2 3 4
1. 00 0. 50 0. 33 0. 25
0. 33 0. 50 1. 00 0. 50
0. 33 0. 25 0. 33 0. 50
1. 00 0. 50 0. 33 0. 25
Input data for marginal totals
*Zone Pr oduct i on At t r act i on
1 10 50
2 20 10
3 30 20
4 40 20
Singly-constrained for attraction, without balancing
k
j
= 1 for all j
This produces the following function values of utilities f(Uij
)
Zone 1 2 3 4
1 0. 37 0. 43 0. 41 0. 39
2 0. 41 0. 43 0. 37 0. 43
3 0. 41 0. 39 0. 41 0. 43
4 0. 37 0. 43 0. 41 0. 39
and so
F
11
= 4.71
F
11
Q
1
Z
1
f U
11
( )
Q
i
f U
i1
( )
i 1 =
n
------------------------------------------ =
F
11
10 50 0 37 ,
10 0 37 , 20 0 41 , 30 0 41 , 40 0 37 , + + +
------------------------------------------------------------------------------------------------------------- =
164 PTV AG
The matrix is produced after the other 15 equations have been calculated.
Result matrix
* Zone number s
1 2 3 4
* 50. 00 10. 00 19. 99 19. 99
* 1 9. 68
4. 71 1. 03 2. 04 1. 90
* 2 20. 47
10. 58 2. 06 3. 64 4. 19
* 3 31. 09
15. 87 2. 80 6. 13 6. 29
* 4 38. 74
18. 84 4. 11 8. 18 7. 61
* 99. 98
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 173).
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 163) shall be calculated using a balancing procedure
(Multi-procedure).
Input file impedances
* Zone number s
1 2 3 4
1. 00 0. 50 0. 33 0. 25
0. 33 0. 50 1. 00 0. 50
0. 33 0. 25 0. 33 0. 50
1. 00 0. 50 0. 33 0. 25
Input data
* ZoneNo Pr oduct i ons At t r act i ons
1 10 50
2 20 10
3 30 20
4 40 20
Scaling according to mean value of both sums
Result matrix
* Zone number s
1 2 3 4
* 50. 00 10. 01 20. 00 20. 00
* 1 10. 01
4. 87 1. 06 2. 11 1. 97
* 2 20. 00
10. 34 2. 01 3. 55 4. 10
* 3 30. 00
165 PTV AG
15. 32 2. 70 5. 91 6. 07
* 4 40. 00
19. 47 4. 24 8. 43 7. 86
* 100. 01
3.2.6 Modal Split (standardized assessment)
The bi-modal mode choice model uses travel time as choice variable. This procedure
estimates the future travel demand by mode based on the current demand and accounting for
an improved PuT offer (for example journey time) for each mode:
with
Types of demand distinguished by the mode choice model
Note: In Germany, a Standardized assessment is required by law for any public transport
rail/road network construction measure. Since 2000, method B2 has to be used for the
Standardized assessment. Outside of Germany or for simple cost-benefit analyses, method
B1 (1993) is recommended.
P
0
m
current share of mode m
P
1
m
future share of mode m
U
0
m
current utility of mode m
U
1
m
future utility of mode m
( )
( )
=
n
1 i
U U
e
0
i
P
U U
e
0
m
P
:
1
m
P
0
i
1
i
0
m
1
m
Private Transport
(without measure)
Public Transport
(without measure)
Impact of
measure
(1) (2) (4)
Private transport
(with measure)
(3) Public Transport
(with measure)
(4)
166 PTV AG
Procedure B1
public transport trips in current state
private transport trips in current state
total trips in current state
.
private transport journey time: current (0) / future (1) state
.
public transport journey time: current (0) / future (1) state
.
no. of transfers: current (0) / future (1) state
.
service frequency: current (0) / future (1) state
Remaining private transport demand
Trips which use private transport in the current and
the future state.
Remaining public transport demand
Trips which use public transport in the current and
the future state.
(1) Demand shifted from private to public transport
Trips which use private transport in the current state
but switch to public transport in the future state.
(2) Demand shifted from public to private transport
Trips which do not exist in the current state, but are
generated by the public transport measure.
(3) Total sum of shifted demand
Total sum of shifted demand =
Demand shifted from private to public transport
Demand shifted from public to private transport
(4) Induced public transport demand
Trips which use public transport in the current state
but switch to private transport in the future state.
0
PuT
T
0
T Pr
T
0
PuT
T
0
T Pr
T
0
Tot
T + =
0
T Pr
JT
1
T Pr
JT
0
PuT
JT
1
PuT
JT
0
PuT
NT
1
PuT
NT
0
PuT
SF
1
PuT
SF
167 PTV AG
B1: Calculation
.
so-called share of high quality public transport: current (0) /
future (1) state
public transport share in current state
public transport share in future state
Input parameters Procedure B1
g0 (constant = 1.0, cf. formula above)
g1 Standard value: 2.600
g2 Standard value: -1.700
private transport trips in future state
PuT trips in future state including induced trips
PuT trips in future state without induced trips
0
PuT
SR
1
PuT
SR
0
Tot
T
0
PuT
T
0
PuT
p =
PuT
p
0
PuT
p
1
PuT
p + =
=
PuT
p
+ + + +
+
1
PuT
1
PuT
1
PuT
1
PuT
1
T Pr
SR 5 g SF 4 g NT 3 g
JT
JT
2 g 1 g
e 1
1
+ + + +
+
0
PuT
0
PuT
0
PuT
0
PuT
0
T Pr
SR 5 g SF 4 g NT 3 g
JT
JT
2 g 1 g
e 1
1
0
Tot
T
1
PuT
p 1
1
T Pr
T
=
1
Ind , PuT
T
1
* PuT
T
1
PuT
T + =
1
T Pr
T
0
Tot
T
1
* PuT
T =
168 PTV AG
Procedure B2
In VISUM, the Modal split calculation methods B1 and B2 are both based on timetable-based
assignment results of
current network status (without measure): Without scenario
future network status (with measure): With scenario
In Germany, the procedure B2 has to be used for the Standardized assessment which is
required by law for any public transport rail/road network construction measure (Version 2000,
by the German Federal Ministry of Transport, Construction and Housing).
The input parameters of the procedures differ. Recommended standard values are listed for g1
to g5. In VISUM, parameter g0 is not 1.1 (thus deviating from the German guidelines), but has
a constant value of 1.
Though the B1 method is not as complex as the B2 method, it provides results of sufficient
quality.
The bi-modal approach uses the modal-split shares of the current state, which are available as
demand matrices for PrT and PuT.
The modal split of a future state is determined by the current modal split and the changes of
the following skims.
private transport journey time (door to door) JT
PrT
(t
Cur
)
public transport journey time (door to door) JT
PuT
no. of transfers in public transport NT
PuT
public transport service frequency SF
PuT
share of high quality transit SR
PuT
, for example light rail as percentage of the trip length
(B1). The term was extended for B2 (roadway supports degree).
induced public transport trips in future state
Input parameters Procedure B2
1
Ind , PuT
T
1
PuT
JT
r
1
PuT
JT
0
PuT
JT
0
PuT
T ,
1
* PuT
T MIN
1
Ind , PuT
T

<

=
min 5 JT JT if ,
5
JT JT
min 5 JT JT if , 1
r
1
PuT
0
PuT
1
PuT
0
PuT
1
PuT
0
PuT
169 PTV AG
3.2.7 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.7.1 Go to the operation
The Go to operation performs a convergence check. It is either checked if an attribute or matrix
has changed by less than a user-defined threshold during the last iteration, or if a specific user-
defined attribute lies under a certain value. The second case might be useful if you add a script
first 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 (operation or group) and
iterates the procedure from there (operation) 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.7.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 operation 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
whereby

3.2.7.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 operation 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
A Result matrix
B Matrix of current iteration
C Matrix average of all previous iterations
i iteration counter
Notes: The iteration counter starts counting from iteration 0 and when Go to operations are
triggered it always uses the innermost loop as point of reference.
During an operation you can exchange the two weightings. However, make sure that one of
the weightings is always 1/(i+1) and the other is i/(i+1).
A
1
i 1 +
----------- B
i
i 1 +
----------- C + =
170 PTV AG
whereby

3.3 Displaying and Editing Matrices
VISUM provides various options for displaying and editing matrices or using them for
calculations.
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,
page 635), others are available as procedures (see User Manual, Chpt. 4, page 813).
A newly calculated attribute value
B Attribute value of current iteration
C Averaged attribute value of all previous iterations
i iteration counter
Notes: The iteration counter starts counting from iteration 0 and when Go to operations are
triggered it always uses the innermost loop as point of reference.
During an operation you can exchange the two weightings. However, make sure that one of
the weightings is always 1/(i+1) and the other is i/(i+1).
A
1
i 1 +
----------- B
i
i 1 +
----------- C + =
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 two matrices
Functions for copying / replacing matrix values Matrix
window
Procedure
Edit individual matrix values interactively x
Set values conditionally x x*
Form constant matrix x x*
Transpose x x
Reflect upper or lower triangle x x
Set diagonal x x*
Copy diagonal to Clipboard
Paste diagonal from Clipboard
x*
171 PTV AG
Chapter 3.3: Displaying and Editing Matrices
* Not a procedure of its own, but possible via Combination of matrices and vectors
3.3.1 Displaying matrices in tabular form
Matrices can be clearly arranged in a table. In VISUM you can edit the layout of the data
displayed in the matrix window in order to enhance the overview (see User Manual, Chpt. 3.3,
page 727):
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 classify the matrix values and display the values of different classes in different
font and background colors.
You can filter the matrix values so that only the rows and columns of your choice are
displayed.
The matrix values can be visualized in an aggregated form without changing the values
themselves.
Arithmetic operations on matrices Matrix
window
Procedure
Round x
Add / subtract matrices x x*
Multiply / divide matrices (elementwise) x
Form reciprocal (elementwise) x x
Raise to power (elementwise) x
Take logarithm (elementwise) x x
Exponential function (elementwise) x x
Forming maximum or minimum x x
Symmetrize matrix (calculate average values pairwise from top and bottom
triangle)
x x
Combination of matrices and vectors x x
Projection: various procedures x
Projection of aggregated areas x
Calculate matrix using marginal totals, i.e. trip distribution (see "Gravity
model calculation" on page 157)
x
Generate main zone matrix, using zone matrix (aggregate) - and generate
zone matrix, using main zone matrix (disaggregate)
x x
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)
172 PTV AG
You can change the alignment of the values and the number of the displayed decimal
places.
3.3.2 Matrix values displayed as 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.11, page 752).
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 177). The intervals can
be stored and used for other applications.
3.3.3 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.
The function offers the option of copying the matrix section below the diagonal into the upper
triangle. The function offers the option of copying the matrix section above the diagonal into the
lower triangle.
3.3.4 Copy, paste and apply diagonal
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.
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.5 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 01. or 0.25, for example.
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.
173 PTV AG
3.3.6 Form reciprocal, raise to power, take logarithm, exponential function
The function offers the possibility of transferring the reciprocal of any given matrix value into
the matrix.
The function offers the possibility of giving an exponent for all matrix values and transferring
the result in each case as the new matrix value.
The function offers the possibility of determining the logarithm for each matrix value and
transferring the result in each case as the new matrix value.
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.
3.3.7 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.
The result matrix then contains the following values for each relation.
The greater of the two values at maximum formation
The smaller of the two values at minimum formation
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 172).
3.3.8 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 787).
3.3.9 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 788).

3.3.10 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.
The matrix values can be projected per row (singly constrained projection regarding the
generation), per column (singly constrained projection regarding the production) or both rows
and columns (doubly constrained projection).
The complexity of the doubly constrained projection is illustrated by the example below.
The aim of this example is to project the origin and destination demand in the following way.
Note: This function allows you to add exponential or BoxCox-transformed complex terms.
174 PTV AG
zone 1 by 10 %
zone 2 by 20 %
Table 43: 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.
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 (stepwise) progression, this process searches for the solution
that best achieves the expected values (see "The multi-procedure according to Lohse
(Schnabel 1980)" on page 174).
The Matrix Editor thus provides the following solution which correctly projects the origin and
destination traffic.
Table 44: Result matrix
The multi-procedure according to Lohse (Schnabel 1980)
With the multi-procedure new traffic flows are calculated in each iteration step F
ij
(Schnabel
1980).
The iteration formula applied is as follows
F
ij
(n+1) = F
ij
(n) q
i
(n) z
j
(n) f(n)
with
Zone 1 2 Origin traffic
1 20 30 50
2 40 50 90
Destination traffic 60 80 140
1 22 33 55
2 48 60 108
1 21 34 55
2 45 62 107
q
i
n ( )
Q
ip
F
ij
Z
jp
Z
j
n ( )
-------------
j
--------------------------------- =
175 PTV AG
This iterative calculation is done repeatedly until the following conditions are met for all
boundary values (origin and destination expected values).
for all zones i
for all zones j
The threshold suggested by Lohse was used. It states that
or
GF: Quality factor
When activating the calibration process, you can set the following parameters for this multi-
procedure.
3.3.11 Converting zone and main zone matrix into each other
When aggregating a zone matrix and a main 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
Q
ip
Desired origin traffic zone i
Z
jp
Desired destination traffic zone j
G
p
Desired total traffic
F
ij
(n) Traffic flow from zone i to zone j in iteration n
Q
i
(n) Origin traffic zone i, iteration n
Z
j
(n) Destination traffic zone j, iteration n
G(n) Total traffic, iteration n
Parameters Description
Maximum number of
iterative steps
1..9999 (as required); the default is 10
Quality factor 1..99 (as required); the default is quality factor = 3
The higher the quality factor, the longer the computing time and the higher the
precision of the calculations.
z
i
n ( )
Z
j p
F
i j
Q
ip
Q
i
n ( )
--------------
i
---------------------------------- =
f n ( )
G
p
G n ( )
------------ =
Q
i
n ( )
Q
ip
-------------- 1
Z
j
n ( )
Z
jp
------------- 1
1
GF Q
i p
( )
----------------------------- =
1
GF Z
jp
( )
---------------------------- =
176 PTV AG
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:
where

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.12 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:
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 window
i, j Zone indices
i, j Main zone indices related to the zone indices
Index(I), Index (J) Number of zone indices belonging to the main zone
b Output matrix (zone matrix)
a Input matrix (main zone matrix)
w Weighting factors
Note: If the denominator of a fraction is zero, weighting will be ignored.
b
ij
w
i
1
w
j
2
w
l
1
w
m
2
m Index J ( )
l Index I ( )
----------------------------------------------------------------------------------------- a
IJ
=
1 2 3
1 1 1 1
177 PTV AG
Matrix chosen as operand
Matrix extended on addition
3.3.13 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:
with
2 1 1 1
3 1 1 1
1 2 4 5
1 2 2 2 2
2 2 2 2 2
4 2 2 2 2
5 2 2 2 2
1 2 3 4 5
1 3 3 1 2 2
2 3 3 1 2 2
3 1 1 1 99 99
4 2 2 99 2 2
5 2 2 99 2 2
Arithmetic mean
Weighted mean
q
i
Matrix value of i. zone
g
i
Weighting of i. zone
n Number of columns or rows
q
i
i 0 =
n
n
---------------------
q
i
g
i
i 0 =
n
g
i
i 0 =
n
------------------------------
178 PTV AG
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:
7 = (66+77+110+111)/(6+7+1+1)
15 = (142+152)/(2+2)
3.3.14 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.
179 PTV AG
Chapter 3.4: Matrix correction
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:
This produces the following matrix:
Sum of the matrix values of all OD pairs from/to 1001..1003 = 1000.
3.4 Matrix correction
You have different possibilities of correcting the demand matrix values with count data.
Updating demand matrix with TFlowFuzzy
Projecting PrT Path Volumes
Calibrating a PrT matrix
3.4.1 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.
Zone number old Zone number new Factor origin traffic Factor destination
traffic
100 1001 0.3 0.1
100 1002 0.5 0.2
100 1003 0.2 0.7
200 2001 0.7
200 2002 0.3
180 PTV AG
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.
The workflow for the matrix calibration is as follows.
You can choose among the following count data:
Link volumes
Origin/destination travel demand per zone
Old
matrix
data
New
(Add
Val)
TFlowFuzzy
New
matrix
Network
model
Demand
matrix
Assignment TFlowFuzzy
Count data
181 PTV AG
Volumes of turns at nodes or main turns at main nodes (as long as they are defined)
Volumes via screenlines
PuT passenger trips
Boarding/alighting passengers at stop areas
Skim data distribution, e.g. journey distance distribution
You can also combine count data.
For the update, the specified count values are compared with the volumes, which result from a
precalculated 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
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 screenlines, 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 f
ij
.
Travel demand is usually described as a matrix, but for our purposes a vector representation
containing all non-zero OD trips is more suitable.
182 PTV AG
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.
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.
A f = v
whereby A is called flow matrix. a
sk
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.
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 << n
2
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).
M
M
M
L
M O M M M
L
L
L
31
f
n 2
f
23
f
21
f
n 1
f
13
f
12
f
0
3 n
f
2 n
f
1 n
f
n 3
f 0
32
f
31
f
n 2
f
23
f 0
21
f
n 1
f
13
f
12
f 0
( )
m
v
3
v
2
v
1
v
r
v L =
3
2
1
3
2
1
32
31
23
21
13
12
0 0 1 0 1 0
1 0 0 0 0 1
0 1 0 1 0 0
1 1 0 0 0 0
0 0 1 1 0 0
0 0 0 0 1 1
alight
alight
alight
board
board
board
t
t
t
t
t
t
183 PTV AG
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 with sets of variables of different
widths which replace strict values.
max q(f), so that A f =
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.
If is already set as a demand from the original matrix, the maximization of q benefits
matrices which slightly differ from the original matrix. The principle can be transferred to the
new optimization problem
max q(f, s, s), so that
A f + s = v
A f - s = v
s 0
s 0
where are 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 , matrices are favored
that fulfill A f = v "best". Doubling the equation appears to be a disadvantage, because this has
s
v
~
v
( )

= =

=
n
1 i
n
1 j
ij
ij
ij
ij
f
f
f
ln f f q
f
i j
v , v
0 s
= =
184 PTV AG
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.
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.
1
0
3 4 5
Membership
function
1
0
z
Membership
function
z-
*s z+
*s
185 PTV AG
Values z, s and are entries for TFlowFuzzy (see User Manual, Chpt. 3.7.1, page 792). 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.
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
* Ti me i nt er val
0. 00 24. 00
* Fact or
1
* Mode of t r anspor t No. 3
* 3 Mode of t r anspor t PuT
* 4 Mode of t r anspor t Pr T
* Number of zones
4
1 2 3 4
*Zone 1 Tot al = 300
0 100 100 100
100 0 100 100
100 100 0 100
100 100 100 0
Counts have since been completed on all links of the network, and the following volumes
obtained.
z the count value itself, where the membership function assumes its maximum
s the distance between the count value, where the membership function drops to value 0
a predefined scaling factor ( > 0)
186 PTV AG
The counted values for this example are based on the assumption that the demand matrix has
since changed as follows.
$VR
* PTV
* Ti me i nt er val
0. 00 24. 00
* Fact or
1
* Mode of t r anspor t No. 3
* 3 Mode of t r anspor t PuT
* 4 Mode of t r anspor t Pr T
* Number of zones
4
1 2 3 4
0 150 100 100
150 0 100 80
100 100 0 100
100 80 100 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 2 3 4
* 346 331 298 281
* 1: 346
0 148 99 99
* 2: 331
148 0 100 83
* 3: 298
99 100 0 99
187 PTV AG
* 4: 281
99 83 99 0
* 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 F
ij
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).
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 k
i
for each count value z
i
.
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 z
i..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 F
ij
matrix of the last assignment serves as the basic matrix.
1 20 30 50
188 PTV AG
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:
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 174).
For the above example the following solution is found:
2 40 50 90
1 22 33 55
2 48 60 108
1 21 34 55
2 45 62 107
189 PTV AG
4 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
The types of impact models
Impedance functions
Paths in PrT and PuT
Skims / indicators
4.1 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.
190 PTV AG
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 service trips.
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.
PrT (see "User Model PrT" on page 195)
PuT (see "User Model PuT" on page 407)
4.1.2 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 489). 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
investment analysis according to recommendations for economic feasibility studies published
191 PTV AG
Chapter 4.2: Impedance functions
by the German FGSV (Road Traffic Research Association in Germany in 1997 (see "Economic
assessment according to EWS" on page 625).
4.1.3 The environmental impact model
VISUM provides three models within the environmental impact model, to calculate the
environmental impacts - noise and pollution emissions, caused by motorized private transport
(see "Environmental impact model and HBEFA" on page 613).
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).
4.2 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 851) and at line blocking per vehicle
combination (see User Manual, Chpt. 7.1.3.2, page 1030).
In VISUM, impedance functions are used in the following contexts.
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.
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
assigns an OD pair or assigns the mode choice for this relation to the effort, which has to
192 PTV AG
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 (service trip,
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 54). 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 54: Impedance calculation for a PuT connection, for clarity illustrated in the unit [min]
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
193 PTV AG
Chapter 4.4: Skims / indicators
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 service trips 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 849) and PuT
(see User Manual, Chpt. 6.1.1.2, page 944). 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 x
ij
for the skim value, refers to the relation from zone i to zone j.
Skims are generally there to calculate the properties of a traffic model. In feed back models
they are also the input data for the demand modeling procedure, 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.
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.
194 PTV AG
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
values with each assignment. These are properties of the total assignment results, i.e., 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 684).
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.
195 PTV AG
5 User Model PrT
The User Model PrT calculates the effect of the infrastructure for private transport on all car
drivers and passengers, but also on non-motorized road users such as cyclists and
pedestrians.
Subjects
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
5.1 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.
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 296).
The Equilibrium assignment distributes demand according to Wardrop's first principle,
which is: 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
196 PTV AG
Chapter 5: User Model PrT
personal travel time.. The state of equilibrium is reached by multi-successive iteration
based on an incremental assignment as a starting solution. 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 301).
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 312).
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 324).
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 332).
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 342).
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 system-
specific road toll value, either for each VISUM route or for link sequences between user-
defined nodes (non-linear toll systems) (see "TRIBUT" on page 353).
In co-operation with the University of Rome, VISUM provides the Dynamic User
Equilibrium (DUE). Additionally, it can regard time-varying capacities as well as road tolls
and includes a departure time choice model (see "Dynamic User Equilibrium (DUE)" on
page 367).
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 (=
197 PTV AG
Chapter 5.2: Example network for the PrT assignment procedures
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 396).
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 45.
5.2 Example network for the PrT assignment procedures
The way the PrT assignment procedures work is described with the example illustrated in
illustration 55. The example analyzes the relation between traffic zone A-Village and traffic
zone X-City. The following assumptions apply:
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.
Traffic demand between A-Village and X-City consists of 2,000 car trips (car.fma matrix)
during the 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.
v
0
Free flow speed [km/h]
t
0
Free flow travel time [s]
v
Cur
Speed in loaded network [km/h]
t
Cur
Travel time in loaded network [s]
R Impedance = f (t
Cur
)
q Volume of a network object [car units/time interval] = sum of volumes of all PrT transport systems
including basic volume (preloaded volume)
q
Max
Capacity [car units/time interval]
Sat Volume/capacity ratio
F
ij
Number of trips [veh/time interval] for relation from zone i to zone j.
F Demand matrix which contains the demand for all OD pairs.
Table 45: Abbreviations used in the User model PrT.
q q
i
PCU
i
( )
i 1 =
NumTSys
q
preloadedVol ume
+ =
198 PTV AG
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.
Illustration 55: Example network
LinkN
o
From
Node
To Node Type Length [m] Capacity [car units/h] v0-PrT [km/h]
1 10 11 20 Federal road 5000 1200 100
2 11 20 20 Federal road 5000 1200 100
3 20 21 20 Federal road 5000 1200 100
4 20 40 90 Rail track 10000 0 0
5 21 30 20 Federal road 5000 1200 100
6 30 31 20 Federal road 5000 1200 100
7 31 40 20 Federal road 5000 1200 100
8 11 41 30 Country road 16000 800 80
Table 46: Example network

11
21
20
10
12
41
40
31 30
village A
city X
1
2 9
6 5
8
11
7 3
10
199 PTV AG
Chapter 5.3: PrT Paths
The example network from Table 46 can be found in the directory
...\VISUM115\Examples\Example_net.
Version file: Example.ver
Assignment parameters file: Auto.par
5.3 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.
Table 47 displays the PrT paths provided by an equilibrium assignment in Example.ver, in link-
based display.
9 40 41 30 Country road 5000 800 80
10 10 12 40 Other roads 10000 500 60
11 12 21 40 Other roads 5000 500 60
LinkN
o
From
Node
Table 46: Example network
Origin zone Destination
zone
Path index Index Link From node To node
100 200 1
1 1 10 11
2 2 11 20
3 3 20 21
4 5 21 30
5 6 30 31
6 7 31 40
100 200 2
1 1 10 11
2 8 11 41
3 9 41 40
100 200 3
1 10 10 12
2 11 12 21
3 5 21 30
4 6 30 31
Table 47: Link-based PrT paths of a PrT assignment
200 PTV AG
For private transport, you can edit paths manually, because paths are available as network
objects here (see "Paths" on page 40).
5.4 Impedance and VD functions
Subjects
Impedance of a PrT route
Predefined VD functions
Example of the calculation of the link impedance
User-defined VD functions
5.4.1 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 201)
Impedances of used turns, which are also called 'node impedance' (see "Impedances at
node" on page 210)
Impedances of the used connectors (see "Impedances of connectors" on page 201)
Impedances of the used main turns (see "Impedances of main turns" on page 202)
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:
Transport system-specific travel time, in loaded network t
Cur
[s]
Link length [m]
Transport system-specific road tolls [money units]
User-defined AddValues
Link type factor [-]
5 7 31 40
Origin zone Destination
zone
Path index Index Link From node To node
Table 47: Link-based PrT paths of a PrT assignment
201 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 867).
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
t
Cur
with a VD function)
Summands, which are not dependent on the network object volume (for example, toll or link
length)
The time t
Cur
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 202).
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 (t
0
_TSys) for free flow is
defined which is calculated from:
link length
permitted speed (v
0
_PrT) of the link used
maximum speed of the transport system (v
0
_PrTSys)
A capacity-dependent impedance function continuously adapts this basic travel time
depending on the current traffic volume (see "Predefined VD functions" on page 202).
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 t
0
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 210).
Impedances of connectors
Connector impedances are regarded as follows:
Absolute connectors are regarded as being volume-dependent. This means, that the TSys-
specific connector time (t
0
_TSys) does not represent actual impedance which is volume-
independent.
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 t
Cur
_TSys will exceed the connector time
t
0
_TSys of each connector (see "Predefined VD functions" on page 202). With a high value
202 PTV AG
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.

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 t
0
of a link can be determined from the link length and the
free-flow speed v
0
. For turns at an intersection, the turn time t
0
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 q
Max
. The result of the VD function is the travel time
in the loaded network t
Cur
. 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 56)
2. a modified BPR function with a different parameter b for the saturated and unsaturated
state (Table 50)
3. a modified BPR function, for which an additional supplement d per vehicle can be specified
in the saturated state (Table 51)
4. the INRETS function of the French Institut National de Recherche sur les Transports et leur
Scurit (illustration 57)
5. a constant function where the capacity does not influence travel time (t
Cur
= t
0
)
Note: The impedance of turns and connectors in contrast to links only depends on the
variable t
Cur
and possibly on the AddValue. Because the impedance of a connector is not
capacity-dependent, the following applies to the access and egress impedance: t
Cur
= t
0
. The
proportional distribution of traffic demand onto different connectors is, however, reached
through a virtual capacity, so that t
Cur
> t
0
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(car-
private) + Demand(HGV) = 100% Connector capacity.
203 PTV AG
6. and several functions for turning processes (i.e. t
0
is added, not multiplied) as well as
function type linear bottleneck which are used by turn type
7. the function ICA-Turn, which is used by lane for precise calculation of turn impedances and
capacities via Intersection Capacity Analysis
8. 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 = sat
crit
Table 48 shows the variables used in the descriptions of the VD functions.
The parameters mentioned in Table 49 apply to all VD functions. Function-specific parameters
are listed with the respective VD function.
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 209).
sat
Volume/capacity ratio
sat
crit
Degree of saturation at which the linear section of the volume-delay function starts
t
cur
Current travel time on a network object in loaded network [s] (t
Cur
)
t
0
Travel time on a network object with free flow time [s]
q Current volume = sum of volumes of all PrT transport systems including preloaded volume
[car units/time interval]
q
max
Capacity [car units/time unit]
Table 48: Variables used in VD functions
a, b ,c User-defined parameters
a [0.00;), b {0.00...10.00}, c [0.00;)
Table 49: Parameters for all VD functions
c
max
q
q
sat
=
q q
i
PkwE
i
( )
i 1 =
NumTSys
q
preloadedVolume
+ =
204 PTV AG
Illustration 56: VD function type BPR according to the Traffic Assignment Manual
sat
crit
sat
crit
= 1
a, b, b ,c Parameters a [0.00;), b, b {0.00...10.00}, c [0.00;)
Table 50: VD function type BPR2: modified BPR
sat
crit
sat
crit
= 1
a, b, c, d a [0.00;), b {0.00 ...10.00}, c [0.00;), d {0.00...100.00}
Table 51: VD function type BPR2: modified BPR
with
a, c a [1.1;100), c [0.00;100)
Table 52: VD function type CONICAL (Spiess)
Volume-delay graph for a=1 and c=1, tCur = t0 f(q/qMax)
0
1
2
3
4
5
6
7
8
9
10
0 0,2 0,4 0,6 0,8 1 1,2 1,4 1,6
q / qMax
f
(
q
/
q
M
a
x
)
b = 2
b = 3
b = 4
b = 5
205 PTV AG
A marginal-cost version of the CONICAL function, proposed by Spiess to calculate a system
optimum instead of user optimum in equilibrium assignment.
The function models queuing at entry legs whose inflow is restricted by ramp metering signals.
with
a, c a [1.1;100), c [0.00;100)
Table 53: VD function type CONICAL_MARGINAL
sat
crit
sat
crit
[0.00;10]
a, b, c, d a [0,0001;100], b [0,0001;10000], c [0.00;100], d [0,0001;10000]
Table 54: VD function type EXPONENTIAL
sat
crit
sat
crit
= 1
q current volume = sum of volumes of all PrT demand segments [car units/time unit] including
basic volume (preloaded volume)
a user-defined parameter a {0.00..1.10}
c user-defined capacity parameter c [0;)
Table 55: VD function type INRETS
q q
i
PkwE
i
( )
i 1 =
NumDSeg
q
preloadedVol ume
+ =
206 PTV AG
Illustration 57: VD function type INRETS
The impedance functions listed in Table 56 are particularly suited to the modeling of turn
impedances. A capacity-dependent wait time is thus added to each basic wait time t
0
.
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 t
0
but multiplied by it.
a, b, c, d 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.
Table 56: VD function types LOGISTIC, QUADRATIC, SIGMOIDAL_MMF_NODES,
SIGMOIDAL_MMF_LINKS
AKCELIK
Table 57: VD function type AKCELIK
Volume-delay graph for c=1, tCur = t0 f(sat)
0
1
2
3
4
5
6
7
8
9
10
0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1 1,1 1,2 1,3 1,4 1,5 1,6
sat
f
(
s
a
t
)
a = 0,0
a = 0,2
a = 0,4
a = 0,6
a = 0,8
207 PTV AG
The function describes delays at nodes with
a = duration in hours
b = family parameter
d = capacity of lane per hour
AKCELIK2
a = duration in hours
b = family parameter
d = 1 / Number of lanes (of the link)
q
max
= 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 58: VD function type AKCELIK2
a, b, t0 Attributes of the particular (main) turn
a: Final A for assignment with ICA
b: Final B for assignment with ICA
t0: Final t0 for assignment with ICA
These are calculated attributes, which cannot be edited by the user.
sat
crit
sat
crit
= 1.1
b b = 3b (thus more steeply compared to sat

sat
crit
)
a
a =
t
0
t
0
=
a and t
0
These values have been selected, so that both branches are differentiatedly linked together
for sat = sat
crit
.
Table 59: VD function type ICA-Turn (illustration 100, query 2: Is the turn share T below p
2
?)
Table 57: VD function type AKCELIK
t
cur
sat ( )
t
0
a sat
b
+ sat s at
crit
t
0
' a' s at
b'
+ sat s > at
crit
=
a
3
--- sat
crit
b b'
t
0
a sat
crit
b
a' sat
crit
b'
+
208 PTV AG
Illustration 58: VD function type LOHSE
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 project-
specific. In this case, you can add your own functions to the pre-defined volume-delay
functions (see "User-defined VD functions" on page 209).
sat
crit
sat
crit
[0.00;10]
a [(a + 1) t
0
] represents t
Cur
with sat = 1
a [0.00;1000]
b Determines the value of the increasing rise up to sat = sat
crit
b [0.00;10]
c Scaling parameter for the determination of the dimensions of q and q
max
c [0.00;100]
Table 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 61: VD function type Linear Bottleneck
LOHSE
0,0
5,0
10,0
15,0
20,0
25,0
30,0
35,0
40,0
45,0
0
,
0
0
0
,
1
0
0
,
2
0
0
,
3
0
0
,
4
0
0
,
5
0
0
,
6
0
0
,
7
0
0
,
8
0
0
,
9
0
1
,
0
0
1
,
1
0
1
,
2
0
1
,
3
0
1
,
4
0
1
,
5
0
1
,
6
0
1
,
7
0
1
,
8
0
1
,
9
0
2
,
0
0
2
,
1
0
2
,
2
0
2
,
3
0
2
,
4
0
2
,
5
0
sat
t
c
u
r
b=2
b=3
b=4
b=5
209 PTV AG
5.4.3 Example of the calculation of the link impedance
Table 62 to Table 65 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.
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
Link length 10000 m
Permitted maximum speed v0 car 130 km/h
Permitted maximum speed v0 HGV 100 km/h
Road toll for cars 1
Road toll for HGV 5
Capacity 3000 car units/h
Car volume 1000 cars/h = 1000 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 62: Input data of the calculation of the link impedance
Car travel time in unloaded network t
0
car = 10000 3.6 / 130 = 277s
Car travel time in loaded network t
Cur
car = 277 (1+(1200/3000)) = 321s
Car speed in loaded network v
Cur
car = 10000 3.6 / 321 = 112 km/h
Table 63: Car travel times and speeds
HGV travel time in unloaded network t
0
HGV = 10000 3.6 / 100 = 360s
HGV travel time in loaded network t
Cur
HGV = MAX (321s; 360s) = 360s
HGV speed in loaded network v
Cur
HGV = 100 km/h
HGV speed only declines if the volume is more than 1644 car units/h, if
t
Cur
= 277 (1+(1644/3000)) = 360s
Table 64: HGV travel times and speeds
Car impedance in loaded network R
Car
= 1 + 0.005 321 = 2.61
HGV impedance in loaded network R
HGV
= 5 + 0.010 360 = 8.60
Table 65: Calculation of link impedance for HGV and car
210 PTV AG
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 VISUM scans at start-up. %APPDATA%\VISUM115\Data\UserDefVDF (see User
Manual, Chpt. 5.2.1.6, page 858).
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 t
Cur
, thus the time required to traverse the node in the turning direction of the route.
For calculating t
Cur
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 real-
life situations on the other.
Turns VD functions (see "Impedance of turns from Turns VD function" on page 212)
Nodes VD functions (see "Impedance of turns from Nodes VD function" on page 212)
Intersection Capacity Analysis ICA (see "Intersection Capacity Analysis according to the
Highway Capacity Manual (ICA)" on page 213)
To use ICA during assignment, select 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 66 is to help you choose the appropriate
calculation model for your project.
Note: A *.bmp file with identical file name which is stored in the same folder will be displayed
for VDF selection.
Model Advantage Disadvantage
Turns VD functions
(see "Impedance of
turns from Turns VD
function" on
page 212)
Little input complexity (per turn
merely capacity and t
0
)
Calculation fast
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)
Table 66: Advantages and disadvantages of the node impedance model
211 PTV AG
Chapter 5.5: Impedances at node
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.
Within an assignment we only restrictedly recommend ICA, due to the known convergence
problems and just for small scale studies with several 100 nodes.
With an equilibrium assignment, best results can be achieved with either the
Equilibrium_Lohse method (see "Equilibrium_Lohse" on page 324) or the From
Nodes VD functions
(see "Impedance of
turns from Nodes VD
function" on
page 212)
Input complexity only slightly larger
than for turn VD functions
(additionally capacity and t
0
for the
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
Intersection Capacity
Analysis ICA (see
"Intersection Capacity
Analysis according to
the Highway Capacity
Manual (ICA)" on
page 213)
Impedance calculation precisely
considers lane allocation and signal
control. Special turn pockets for
example, are capacity-increasing
and dependent on the entered signal
timing, protected and permitted turns
are calculated correctly
Input complexity considerably higher:
Instead of capacity and t
0
, model the
lane allocation at the node and -
where available - the signal control in
detail
Calculation more time consuming
Assignment convergence slow due to
the inseparable impedance model,
sometimes without additional
measures not at all
Node impedance
calculation by lane
turn (see "Assignment
with ICA" on
page 332)
Convergence is reached by regular
adjustment of the Turns VDFs to the
wait times and capacities calculated
by ICA.
The HCM 2000 method used for ICA
regards the lane allocation and
conflicting turn flows in detail.
Increased efforts required for the
comprehensive modeling of
geometry and control at the nodes to
be regarded.
Comparably computation time-
consuming.
Model Advantage Disadvantage
Table 66: Advantages and disadvantages of the node impedance model
212 PTV AG
previous assignment with ICA method(see "Assignment with ICA" on page 332), 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.
5.5.1 Impedance of turns from Turns VD function
In the simplest calculation model t
Cur
, the time requirement of a turning vehicle is calculated
from the turning time t
0
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 202) as VD functions or select a user-defined functional form (see "User-defined VD
functions" on page 209). Typical Turn VD functions make up the sum (not the product) of t
0
and
a saturation-dependent term. An example for this is, are the VD functions Akcelik, Exponential,
Constant, Logistic, Quadratic and TMODEL_Nodes.
The attributes mentioned in Table 67 are considered for the calculation.
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.39, page 492).
The attributes mentioned in Table 68 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 direction of the turn
Table 67: Attributes for the impedance calculation from Turns VD function
Network
object
Turn Capacity
PrT
The capacity of the turns 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
Table 68: Attributes for the impedance calculation from Node VD function
213 PTV AG
Turn time penalties are calculated according to the following formula:
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
t
Cur
(t) = delay(t) + delay(n) for all turns t via node n
IF n has at least one link with TModelSpecial = 1, THEN
t
Cur
(a) = delay(t) for all turns t with a 'from link' to which TModelSpecial = 0 applies
t
Cur
(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 200). They can also be used to model volume-
dependent wait times for turns or complete nodes (see "Impedance of turns from Turns VD
function" on page 212 and "Impedance of turns from Nodes VD function" on page 212).
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.

For intersection points of the same level, the calculation differentiates between the following
control types (attribute control type at node):
Uncontrolled nodes (see "Uncontrolled nodes" on page 214)
Signalized intersections (see "Signalized nodes (HCM 2000 Chapter 16)" on page 214)
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 Stops
(HCM 2000 Chapter 17)" on page 234)
All-Way stops (only for North America) (see "All-Way stop (HCM 2000 Chapter 17)" on
page 243)
Node t0 PrT The additional time required for a non-prioritized turning movement (all the
same) in unloaded state
Network
object
Table 68: Attributes for the impedance calculation from Node VD function
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 in the German VISUM manual for a better traceability in the original document.
214 PTV AG
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 254).
The method described in the Highway Capacity Manual 2010, chapter 21 (see
"Roundabouts according to the HCM 2010 method" on page 250).
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.
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.
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 212),
however without a term for each turn.
The VISUM attributes listed in Table 69 are considered for the calculation.
5.5.3.2 Signalized nodes (HCM 2000 Chapter 16)

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.4.1, page 58).
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.
Network
object
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 69: Attributes for the calculation regarding uncontrolled nodes
Note: In the HCM 2010, signalized nodes are described in chapter 18.
215 PTV AG
The basic flow chart for performing capacity analyses for signalized intersections is displayed
in illustration 59. 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.
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.

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.
Illustration 59: Capacity analysis process for signalized nodes

If you use the HCM 2000 or HCM 2010 operations model for signalized nodes, the VISUM
attributes in Table 70 will have an effect. Make sure that they are set to realistic values prior to
running the analysis.
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.
Note: For HCM 2010, the corresponding flow diagram can be found in HCM 2010, page 18-
32.
I n pu ts
Ge ometry
Vol umes
Signal timin g
L an e Gro up s &
Dem an d Ad j
L ane Gro upi ngs
Peak hour fa ct or
Sat u rat i o n Fl ow Ra t e
(Capa ci t y)
Basi cs
Adj ustmen t Fa ct ors
Cap ac i t y An al ysi s
V/C Ra ti o
Average Del ay
Level o f Servi ce
Qu eue s
216 PTV AG
Alternatively to the calculation method according to HCM, you can apply one of the following
methods:
ICU1
ICU2
Circular 212 Planning
Circular 212 Operations
These methods differ from HCM 2000 in only two aspects:
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 supports the connection of external RBC controls. These are no fixed time
controls. HCM 2010 provides a calculation method for those controls. This method has been
implemented in VISUM. For the description of this method, please refer to HCM 2010, page
31-10 et seqq.
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 required per car
unit
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 Initial volume adjustment to peak period; volumes are
multiplied with both node and turn adjustment factors
Node ICALossTime Used in step 9 Only needed for signal group-based signal
control or if no signal control is modeled. For other types of
signal control the value is inferred automatically.
Node ICASCActualCoordinate
d
Indicates whether the SC is coordinated
Node ICAIsCBD Is the node located in the Central Business District?, used in
Step 6e
Node Sneakers 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
Geometry All Geometry data of lanes, lane turns and crosswalks
Table 70: Input attributes for signalized nodes
217 PTV AG
Turn ICAPHFVolAdj Initial volume adjustment to peak period; volumes are
multiplied by both node and turn adjustment factors
Turn LaneWidth Lane width, used in step 6a
Turns 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
SCJ Used intergreen method Is used in step 9 for loss time calculations
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 NumVehicles 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 required per
car unit.
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 required per car unit.
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 turn-
related 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.
218 PTV AG

Output is possible through the attributes listed in Table 71.
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.
Notes: The link attribute Turn on red is not regarded for calculation.
The value Width of lanes is not regarded for calculation. Instead, the value Lane width of
turns is regarded.
Network
object
Node VolDesign [Veh] PrT The volume in [veh/h] passed into the HCM calculation,
as defined in the procedure parameters
Node VolDesign [PCU] PrT The volume in [PCU/h] passed into the HCM
calculation, as defined in the procedure parameters
Node DesignVolCapRatio PrT The volume/capacity ratio based on the above design
volume
Node TurntCurMax/Mean/Tot Sum, average, max of turn tCur. Now obsolete, since
available as indirect attributes, but retained for
backward compatibility.
Node LOS
Node LOSAvgDelay
Turns VolDesign [Veh] PrT The volume in [veh/h] passed into the HCM calculation,
as defined in the procedure parameters
Turn VolDesign [PCU] PrT The volume in [PCU/h] passed into the HCM
calculation, as defined in the procedure parameters
Turn ICAFinalSatFlowRate After all adjustments
Turn ICAFinalVol After all adjustments
Turn ICAFinalCap Effective capacity, taking into account all opposing
flows etc.
Turn ICABackOfQueueForDefPerc Percentile of queue length. Specify in the procedure
parameters which percentile is calculated.
Turn tCur-PrTSys TSys-specific travel time tCur in loaded network
Turn LOS Level of service of the turn
Table 71: Output attributes for signalized nodes
219 PTV AG
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 (HCM 2000 Chapter 17)" on page 243). You can overwrite a
lane's utilization share within its lane group, if applicable (lane attribute ICAUtilShare).
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:
v
i
= v
g
/ PHF
where
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.
Turn ICACalculatedFollowUpTime Follow-up time used when calculating
Turn ICA back of queue for defined
percentile
Percentile of queue length
Turn ICA average back of queue Average queue length
Turn ICACalculatedCriticalGap Critical gap used when calculating
v
i
adjusted volume for lane group i
v
g
unadjusted (input) volume for lane group g
PHF peak hour factor (0 to 1.0)
Network
object
Table 71: Output attributes for signalized nodes
220 PTV AG
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.
P
LT
= v
LT
/ v
i
P
RT
= v
RT
/ v
i
where
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 usually is 1,900 vehicles per hour per lane (vphpl) for HCM 2000 and
HCM 2010.
For the computation variants ICU1 and ICU2, the ideal saturation flow rate is 1,600 vehicles
per hour per lane instead. For the Circular 212 variant, it is taken from the table below:
This number decreases due to various factors. The SFR is defined as:
s
i
= (s
o
)(N) (f
w
)(f
HV
)(f
g
)(f
p
)(f
a
)(f
bb
)(f
Lu
)(f
RT
)(f
LT
)(f
Lpb
)(f
Rpb
)
where
P
LT
proportion left turn volume by lane group
P
RT
proportion right turn volume by lane group
v
i
adjusted volume by lane group
v
LT
volume of left turning vehicles by lane group
v
RT
volume of right turning vehicles by lane group
Method 2 stages 3 stages 4+ stages
Planning 1,500 1,425 1,375
Operations 1,800 1,720 1,650
s
i
saturation flow rate of lane group i
s
o
ideal saturation flow rate per lane (usually 1,900 vphpl)
N number of lanes in lane group
f
w
factor for lane width adjustment
f
HV
HGV adjustment factor
221 PTV AG
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 f
w
(HCM
2010, page 18-36), f
Lpb
and f
Rpb
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 s
o
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 space
needed per PCU.
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 s
o
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:
Here, s
o
is the ideal saturation flow rate, n is the number of vehicles which can be
accommodated on the pocket, g
i
is the effective green time and s
f
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 s
f
is as follows:
f
g
adjustment factor for approach grade
f
p
adjustment factor for parking
f
a
adjustment factor for the position of the link to city center (CBD true/false)
f
bb
adjustment factor for bus stop blocking
f
Lu
adjustment factor for lane usage
f
RT
adjustment factor for right turns
f
LT
adjustment factor for left turns
f
Lpb
adjustment factor for pedestrians and bicyclists on left turns
f
Rpb
adjustment factor for pedestrians and bicyclists on right turns
s
f
s
o
min s
o
n 3600
g
i
------------------- ,

+ =
s
f
s
ST
s
LT
v
LT
v
LT
v
ST
-------------------- s
ST
v
ST
v
LT
v
ST
+
---------------------- s
LT
+
-------------------------------------------------------------------------- =
222 PTV AG
Here, v
LT
and v
ST
are the volumes of the left and the straight turns, s
LT
is the ideal saturation
flow rate of the left turn - therefore 1,900 vphpl - and s
ST
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:
g
i
= G
i
+ l
i
where
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:
c
i
= s
i
(g
i
/ C)
where
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.
where
g
i
effective green time per lane group
G
i
green time per lane group
l
i
loss time adjustment per signal group
c
i
capacity i
s
i
saturation flow rate i
C cycle time
g
i
/ C green ratio i
X
c
critical saturation (v/c ratio) per intersection
(v/s)
ci
volume/capacity ratios for all critical lane groups
( )
L C
C
i
ci
s v
c
X
223 PTV AG
Below is an example calculation of critical lane group per signal stage with overlap.
For computation variant ICU1, X
c
is defined as follows:
For computation variant ICU2, X
c
is defined as follows:
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.
d
i
= d
Ui
PF + d
Ii
+ d
Ri
where
In HCM 2010, the equation looks likewise. However, factor PF has been implemented in factor
d
Ui
. For the description of the calculation procedure, please refer to HCM 2010, page 18-45.
where
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:
C cycle time
L loss time total of the signal groups of all critical lane groups
d
i
mean delay per vehicle for lane group
d
Ui
uniform delay
d
Ii
inkremental delay (stochastic)
d
Ri
delay residual demand
PF permanent adjustment factor for coordination quality (see "Signal coordination (Signal offset
optimization)" on page 262)
f
PA
lookup value (HCM attachment 16 12) based on arrival type
R
P
lookup value (HCM attachment 16 12) based on arrival type
X
c
v
s
--

ci
i
L
C
--- - + =
X
c
v
s
--

ci
i
1
1
C
L
--- -

1
------------------ + =
( ) ( )
( ) C
i
g 1
PA
f C
i
g
p
R 1
PF
=
( )
( ) ( ) [ ] 1 ,
i
X min C
i
g 1
2
C
i
g 1
C 5 . 0
Ui
d

=
224 PTV AG
where
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:
where
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:
where
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.
d
Ui
uniform delay for lane group i
g
i
effective (actual) green time
X
i
= v/c volume/capacity ratio
d
Ii
incremental (random) delay for lane group i
c
i
capacity for lane group i
X
i
= v/c volume/capacity ratio
T duration of analysis period (hr) (default 0.25 for 15 min)
k
i
lookup value (HCM attachment 16 13) based on the controller type
I
i
upstream filtering / metering adjustment factor (set to 1 for isolated intersection)
d
Ri
residual demand delay for lane group i
Q
bi
initial unmet demand at the start of period T in vehicles for lane group (default 0)
c
i
capacity
u
i
delay parameter for lane group (default 0)
t
i
duration of unmet demand in T for lane group (default 0)
( ) ( )

+ + =
T
i
c
i
X
i
I
i
k 8
2
1
i
X 1
i
X T 900
Ii
d
( )
T
i
c
i
t
i
u 1
bi
Q 1800
Ri
d
+
=
225 PTV AG
where
step 12: Delay calculation for the intersection
The intersection delay is calculated as the weighted delay for each approach.
where
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.
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:
d
A
mean delay per vehicle for approach A
d
i
delay for lane group i
v
i
volume for lane group i
d
i
mean delay per vehicle for intersection I
d
A
delay for approach
V
A
volume for approach
LOS Mean delay/vehicle
A 0 10 sec.
B 10 20 sec.
C 20 35 sec.
D 35 55 sec.
E 55 80 sec.
F 80 + sec.
LOS volume/saturation flow rate
A 0.000 - 0.600
B 0.601 - 0.700
C 0.701 - 0.800
D 0.801 - 0.900
E 0.901 - 1.000
=
i
V
i
V
i
d
A
d
=
A
V
A
V
A
d
I
d
226 PTV AG
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 = Q
1
+ Q
1
where
step 14a: Calculation of the number of residual vehicles after cycle 1
Q
1
represents the number of vehicles that arrive during the red stages and during the green
stages until the queue has dissipated.
where
where
F >1.000
Q mean queue length maximum distance measured in vehicles the queue extends on
average signal cycle
Q
1
mean queue length for uniform arrival with progression adjustment
Q
2
incremental term associated with random arrival and overflow to next cycle
PF
2
progression factor 2
v
i
volume of lane group i per lane
C cycle time
g
i
effective green time of lane group i
X
i
volume/capacity ratio of lane group i
PF
2
progression factor 2
v
i
volume per lane of lane group i
C cycle time
g
i
effective green time lane group i
LOS volume/saturation flow rate
( )

=
C
i
g
i
X , 1 min 1
C
i
g
1
3600
C
i
v
2
PF
1
Q

=
i
s
i
v
p
R 1
C
i
g
1
i
s
i
v
1
C
i
g
p
R 1
2
PF
227 PTV AG
step 14b: Calculate second-term of queued vehicles, estimate for mean
overflow queue
where
k = 0.12 I (s
i
g
i
/ 3600)0.7 for fixed time signal
k = 0.10 I (s
i
g
i
/ 3600)0.6 for demand-actuated signal
step 15: Calcualtion of the queue length percentile
After calculating the mean back of queue, the percentile of the back of queue is calculated as
follows:
where
s
i
saturation flow rate for lane group i
R
P
platoon ratio based on lookup table for arrival type
T analysis period (usually 0.25 for 15 minutes)
k adjustment factor for early arrival
Q
b
initial queue at start of period (default 0)
c
i
capacity for lane group i
i upstream filtering factor (set to 1 for isolated intersection)
Q average queue length
percentile pre-timed signal actuated signal
70% P1 P2 P3 P1 P2 P3
85% 1.2 0.1 5 1.1 0.1 40
90% 1.4 0.3 5 1.3 0.3 30
95% 1.5 0.5 5 1.4 0.4 20
98% 1.6 1.0 5 1.5 0.6 18
1.7 1.5 5 1.7 1.0 13
( ) ( ) ( ) ( ) ( ) ( )
( )

+ + + + + =
2
T
i
c
b
kQ 16
T
i
c
i
kX 8
2
T
i
c
b
Q 1
i
X T
i
c
b
Q 1
i
X T
i
c 25 . 0
2
Q

+ =
3
P
Q
e
2
P
1
P Q
%
Q
228 PTV AG
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 220) which involves several adjustment factors.
Step 6 a: Calculate lane width adjustment factor
where
This method differs in HCM 2010. For a description, please refer to HCM 2010, page 18-36.
Step 6b: Calculate heavy goods vehicle factor
where
Step 6c: Calculate approach grade adjustment factor
where
Step 6d: Calculate parking adjustment factor
f
P
is calculated as follows:
where
f
w
lane width adjustment factor
H mean lane width ( 8) (ft)
f
HV
adjustment factor for heavy goods vehicles
%HV percentage of HGV per lane group
E
P
passenger car equivalent factor (2.0 / HV)
f
g
adjustment factor for approach grade
%G approach grade as percentage (-6 % bis +10 %)
f
p
parking adjustment factor (1.0 if no parking, else 0.050)
N
m
number of parking maneuvers per hour (only for right turn lane groups) (0 to 180)
( )
30
12 W
1
w
f

+ =
( ) 1
T
E HV % 100
100
HV
f
+
=
200
G %
1
g
f =
N
3600
m
N 18
1 . 0 N
f

=
229 PTV AG
In VISUM, enter f
P
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
f
a
= 0.9 if link is in the city center (CBD), otherwise 1.0
where
Step 6f: Calculate bus stop blocking factor
where
In VISUM, enter f
bb
which is calculated by the formula, as attribute ICA bus blockage directly
at the node leg.
Step 6g: Calculate lane utilization adjustment factor
where
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).
Step 6h: Calculate right turn adjustment factor
where
f
a
adjustment factor for position
CBD indicates a central business district
f
bb
bus stop blocking adjustment factor ( 0.05)
N
B
number of bus stop events per hour (does not apply to left turn lane groups) (0 to 250)
f
Lu
adjustment factor lane utilization
v
g
unadjusted (input) volume for lane group g
v
gl
unadjusted (input) volume for lane with highest volume in lane group (veh per hour)
N
3600
B
N 4 . 14
N
bb
f

=
( ) N
1 g
v
g
v
Lu
f =
f
RT
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
=
230 PTV AG
The calculation according to HCM 2010 differs. For shared lanes, the adjustment factor is no
longer explicitly calulated. 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:
where
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
The general equation for calculating f
LT
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:
f
RT
right turn adjustment factor ( 0.05)
P
RT
proportion of right turn volume for lane group
f
LT
adjustment factor for left turns
P
LT
proportion of left turn volume for lane group
f
LT
0.95 for exclusive left turn lane (protected phasing)
1
1.0 0.05 P
LT
+
----------------------------------- for shared left turn lane (protected phasing)
see equations below for permissive phasing
=
231 PTV AG
f
LTmin
= 2 (1 + P
L
) / g
g
u
= g - g
q
(if g
q
0, else g
u
= g)
where
Note that opposing volume is calculated from the signal groups that occur during the same
green time as the subject lane group. 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.
f
LT
general left turn adjustment factor for permitted phasing
f
LTmin
minimum value for adjustment factor
g effective permitted green time for left turn lane group
g
u
effective permitted green time when lefts filter through opposing traffic
P
L
proportion of left turning vehicles in the lane
E
L1
through car equivalent for permitted left turns (veh/hr/lane) (lookup table based on opposing
volume)
g
q
effective permitted green time when lefts are blocked and opposing queue clears
g
o
effective permitted green time for opposing traffic
v
olc
adjusted opposing volume per lane per cycle =
N
o
number of lanes in opposing lane group
v
o
adjusted opposing volume
f
LUo
opposing lane utilization factor (see above)
qr
o
opposing queue ratio = max[1 - R
po
(g
o
/ C), 0] (R
po
= lookup based on arrival type
t
l
loss time for left-turn lane group
f
LT
g
u
g
-----

1
1 P
L
E
L1
1 ( ) +
-------------------------------------------

f
LTmin
f
LT
1 ( ) =
P
L
1
N 1 ( ) g
g
u
E
L1
4.24 + ( )
---------------------------------------- + =
g
q
v
ol c
qr
o
0.5 v
ol c
1 qr
o
( ) g
o
[ ]
--------------------------------------------------------------- t
l
=
v
o
C
3600 N
o
f
LU
o

-------------------------------------
232 PTV AG
Step 1: Determination of the pedestrian occupancy rate OCC
pedg
.
The pedestrian occupancy rate OCC
pedg
is derived from the volume. The following applies.
Here, v
pedg
is the pedestrian flow rate, v
1
pedg
and v
2
pedg
are the pedestrian volumes of the
crosswalks, C is the cycle time of the signal control and g
1
p
and g
2
p
indicate the duration of
the green for the pedestrians.
Step 2: Determination of the relevant occupancy rate of the conflict area OCC
r
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:
OCC
r
= OCC
pedg
Decisive for left turns from one-way roads is, that there is no opposite vehicle flow.
Case 2: Right turn movements with bicycle conflicts
Here, straight turns of bicyclists are assumed.
OCC
bicg
= 0.02 + v
bicg
/ 2700
OCC
r
= OCC
pedg
+ OCC
bicg
- (OCC
pedg
)(OCC
bicg
)
Here, v
bicg
is the bicycle flow rate, v
bic
is the bicycle volume, C is the cycle time of the signal
control, g is the effective green time of the lane group, and OCC
bicg
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 g
q
and g
p
. g
q
is the clearing time of the vehicle
Note: At a leg which is a channelized turn no conflicts occur between right turn movements
and 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, g
p
= 0 is assumed.
v
pedg
min 5000 v
ped
1 C
g
p
1
----- v
ped
2 C
g
p
2
----- + ,

=
OCC
pedg
v
pedg
2000 falls v
pedg
1000 ,
0 4 , v
pedg
10000 + else ,
=
v
bicg
min 1900 v
bi c
C
g
--- - , ( ) =
233 PTV AG
flow on the opposite leg, and g
p
is the green time for the conflicting pedestrians. The
following applies
g
p
= max(g
1
p
, g
2
p
)
Case 3a: g
q
g
p
In this case, the calculation is shortened and the following applies
f
Lpb
= 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: g
q
< g
p
The following applies
Here, OCC
pedu
is the occupancy rate of pedestrians after the clearance of the vehicle flow
on the opposite leg, and OCC
pedg
is the pedestrians occupancy rate.
Step 3: Determination of the adjustment factors for pedestrians and bicyclists on permitted
turns A
pbT
Here, two cases are distinguished with regard to the values N
turn
which is the number of
lanes per turn and N
rec
, which is the number of lanes per destination leg.
Case 1: N
rec
= N
turn
Here applies A
pbT
= 1 - OCC
r
Case 2: N
rec
> N
turn
Here, vehicles have the chance to give way to pedestrians and bicyclists. The following
applies
A
pbT
= 1 - 0.6 OCC
r
Step 4: Determination of the adjustment factors for the saturation flow rates for pedestrians
and bicyclists f
Lpb
und f
Rpb
.
f
Lpb
is the adjustment factor for left turns, and f
Rpb
is the adjustment factor for right turns.
f
Rpb
= 1 - P
RT
(1 - A
pbT
) (1 - P
RTA
)
f
Lpb
= 1 - P
LT
(1 - A
pbT
) (1 - P
LTA
)
P
RT
and P
LT
represent the proportions of right turn and left turn movements in the lane
group, and P
RTA
and P
LTA
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).
OCC
pedu
OCC
pedg
1 0 5 ,
g
q
g
p
-----

=
OCC
r
OCC
pedu
e
5 3600 ( ) v
0
[ ] =
234 PTV AG
5.5.3.3 Two-Way Stops (HCM 2000 Chapter 17)

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 60.
Illustration 60: 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 72 will have an effect. Make sure that they are set to realistic values prior to running the
analysis.
Notes: For the description of this signalization type, please refer to HCM 2010 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 modelled 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.
Network objects Attribute Description / Effect
Link ShareHGV 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
Table 72: Input attributes for the calculation of two-way stops
Inputs
Geometry
Volumes
%HGV, Ped Vol
Volume
PHF
Identify Conflicts
Gap & Foll ow-Up
Times
Basics
Adjustment Factors
Potential Movement
Capacity
Capacity Analysis
Delay, LOS, Queues
235 PTV AG
Output is available through the same attributes as for signalized nodes (Table 71).
The method works with movements (Left, Through and Right) at each approach. Each
movement is ranked according to Table 73.

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.
Node ICAPHFVolAdj Initial volume adjustment to peak period volume; volumes
are multiplied with both node and turn adjustment factors
Turn ICAPHFVolAdj Initial volume adjustment to peak period; volumes are
multiplied with both node and turn adjustment factors
Turn Preset critical gap Optionally, you can overwrite the critical gap, used in step 3
Turn Preset follow-upp time Optionally, you can overwrite the follow-up time, used in step
4
Rank
1 Major Through
Major Right
Minor Ped Crossing
2 Major Left
Minor Right
Major Ped Crossing
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
3 Minor Through
4 Minor Left
Table 73: 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.
Table 72: Input attributes for the calculation of two-way stops
236 PTV AG
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 74 shows the equations for conflicting volumes.
where
There is a number of cases where the conflicting volume is adjusted:
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.
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 222).
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.
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 74: Calculation of the conflicting volumes
O Opposite direction
T Through
R Right
L Left
N Number of through lanes
J Major
i Minor
F far (for minor through/left turns the second major flow encountered )
ToP Approach (to) with pedestrian crosswalk
FrP Exit (from) with pedestrian crosswalk
237 PTV AG
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.

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:
t
cx
= t
cb
+ (t
cHV
P
HV
) + (t
cG
G) - t
cT
- t
3LT
where
The other adjustment factors are:
The base values for the critical gap are calculated as shown in Table 75.
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.
t
cx
critical gap for movement x
t
cb
base critical gap (see Table 75)
t
cHV
P
HV
adjustment factor for heavy vehicles percent heavy vehicles
t
cG
G adjustment factor for grade grade (as a decimal)
t
cT
two stage adjustment factor (currently set to 0 for one stage modeling)
t
3LT
critical gap adjustment factor for geometry
Movement Base critical gap value t
cb
< 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 75: Base values for the critical gap
=
otherwise 0,
on intersecti - T at left minor for , 7 . 0
LT 3
t
otherwise 1,
through and left minor for 0.2,
right minor for , 1 . 0
cG
t
street major lane - four for 2,
street major lane - two for 1,
cHV
t
238 PTV AG
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
The other adjustment factors are:
Follow-up times are calculated according to Table 76.
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:
with
t
fx
follow-up time for movement x
t
fb
base follow-up time (Table 76)
t
fHV
P
HV
follow-up time adjustment factor for heavy vehicles percent heavy vehicles
Movement Base follow-up time value t
fb
Major Left 2.2
Minor Right 3.3
Minor Through 4.0
Minor Left 3.5
Table 76: Follow-up times
c
px
potential capacity for movement x (veh/hr)
v
cx
conflicting flow for movement x (conflict/hr)
t
cx
critical gap for movement x
t
fx
follow-up time for movement x
=
street mjaor lane - four for 1.0,
street major lane - two for , 9 . 0
fHV
t
( )
( )
=
3600 t v
e 1
3600 t v
e
cx
v
px
c
fx cx
cx cx
239 PTV AG
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:
where
= probability impeding vehicle movement i is not blocking subject movement
= probability impeding ped movement j is not blocking subject movement
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 77:
where
c
mx
movement capacity for movement x (veh/hr)
c
px
potential capacity for movement x (veh/hr)
v
i
volume movement i
v
j
volume pedestrian flow j (peds/hr)
w lane width (ft), standard value 12 ft.
S
P
pedestrian walking speed (ft/s), standard value is 4 ft/s
Movement Rank Impeding movements
Major Through 1 None
Major Right 1 None
Major Left 2 ToP
Minor Right 2 FrP, ToP
Minor Through 3 JL, JLF, FrP, ToP
Minor Left 4 JL, JLF, OT, OR, FrP, ToP
Table 77: Impeding movements
=

movements
pedestrian Impeding j
pj
p
x nt Moveme
than rank greater
with Movements i
vi
p
px
c
mx
c
mi
c
i
v
1
vi
p =
P
pj
1
v
j
w
S
p
-----

3600
------------------- =
240 PTV AG
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:
where

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.
J Major
i Minor
O Opposite direction
T Through
R Right
L Left
F far (for minor through/left turns the second major flow encountered )
ToP Approach (to) with pedestrian crosswalk
FrP Exit (from) with pedestrian crosswalk
p
vJL
modified probability of impeding maJor left
p
vJL
unmodified probability of impeding maJor left
v
JT
volume major through
v
JR
volume major right (0 if exclusive right turn lane)
s
JT
sat flow major through (1700 standard)
s
JR
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.
=
JR
JR
JT
JT
vJL
vJL
s
v
s
v
p
p
1
1
1 '
pJP
p
pIP
p
vIR
p
i
p
4 vR
p
ii
p 6 . 0 )
3
ii
p
ii
p
(
ii
p 65 . 0
i
p
vIT
p
vJLF
p
vJL
p
ii
p
=
+
+
=
=
241 PTV AG
where
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.
where
step 8: Calculate delay
The calculation of control delay is defined as follows:
where
p
vJL
probability of impeding maJor left near
p
vJLF
probability of impeding maJor left far
p
vIT
probability of impeding minor through
p
vR4
probability minor left (rank 4)
p
vIR
probability minor right (rank 2)
p
pIP
probability minor pedestrian
p
pJP
probability major pedestrian
C
SH
shared lane capacity
v
i
volume minor street movement i
c
m
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.
d
x
mean delay per vehicle for movement x
c
mx
capacity for movement (shared lane x, C
SH
)
v
x
capacity for movement (shared lane x, V
SH
)
=
m
c
i
v
i
v
SH
C
5
T 450
mx
c
x
v
mx
c
3600
1
mx
c
x
v
1
mx
c
x
v
T 900
mx
c
3600
x
d +
+ =
242 PTV AG
A similar formula is used for the calculation of either two-way control type (yield or stop):
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:
(5)
where
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 78 based on intersection delay.
d
R1
delay rank 1 vehicles (s/veh)
N number of through lanes per direction of the major flow
p
vJL
probability for an adjustment factor impeding major left (5)
d
JL
delay to major left (s/veh)
v
T
shared through lane volume (for multilane sites, only the volume in the shared lane)
v
R
shared right turn lane volume (for multilane sites, only the volume in the shared lane)
A 0 10 sec.
B 10 15 sec.
C 15 25 sec.
Table 78: Allocation of a LOS to the mean delay per vehicle
d
3600
c
mx
------------ 900T
v
x
c
mx
-------- 1
v
x
c
mx
-------- 1

2
3600
c
mx
------------

v
x
c
mx
--------
450T
-------------------------- + + 5 min
v
x
c
mx
-------- 1 , + + =
=
>
+
=
1 N when
JL
d )
vJL
p - (1
1 N when
R
v
T
v
)
N
T
v
(
JL
d )
vJL
p 1 (
1 R
d
243 PTV AG

The intersection queue length calculation is:
where
5.5.3.4 All-Way stop (HCM 2000 Chapter 17)

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 61. 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
D 25 35 sec.
E 35 50 sec.
F 50 + sec.
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).
Q
95x
queue length 95th percentile for movement x (veh)
c
mx
capacity for movement (shared lane x, C
SH
)
v
x
movement volume (shared lane x, V
SH
)
Note: The calculations described in HCM 2010 and HCM 2000 are identical.. In HCM 2010,
please refer to chapter 20. 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.
Table 78: Allocation of a LOS to the mean delay per vehicle
=
3600
mx
c
T 150
mx
c
x
v
mx
c
3600
2
1
mx
c
x
v
1
mx
c
x
v
T 900
x 95
Q
244 PTV AG
(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.
Illustration 61: 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 79 will have an effect. Make sure that they are set to realistic values prior to running
the analysis.
Network
object
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 ICAPHFVolAd
j
Initial volume adjustment to peak period. Volumes are multiplied with both
node and turn adjustment factors.
Geometry All Geometry information on lanes, lane turns and crosswalks
Turn ICAPHFVolAd
j
Initial volume adjustment to peak period. Volumes are multiplied with both
node and turn adjustment factors.
Table 79: Input attributes for an All-Way stop node
Input s
Geometry
Volumes
Volume
PHF
Lane volumes
Bas e Headway
Adjust ments
Final Degree of
Ut ilizat ion
Ser vice Time and
Capac it y
Delay and LOS
Pr obabilit y St at es
Depart ure Headway
245 PTV AG
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:
h
adj
= h
LTadj
p
LT
+ h
RTadj
p
RT
+ h
HVadj
p
HV
where
The adjustment factors are listed in Table 80.
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
where
This probability states calculation has a few parts. For each lane type j the P(a
j
) is calculated.
P(a
j
) is calculated based on a lookup table (Table 81).
h
adj
follow-up time adjustment
h
LTadj
follow-up time adjustment for left turns
h
RTadj
follow-up time adjustment for right turns
h
HVadj
follow-up time adjustment for heavy vehicles
P
LT
proportion of left-turning vehicles on approach
p
RT
proportion of right-turning vehicles on approach
p
HV
proportion of heavy vehicles on approach
Number of lanes of the subject approach Adjustment factor Saturation Mean follow-up time
LT RT HV
1 0.2 0.6 1.7
2+ 0.5 -0.7 1.7
Table 80: Adjustment factors
P(i) probability for combination i
P(a
j
) probability of degree-of-conflict (DOC) for combination i lane type j
a
j
1 or 0 depending on lane type j (see Table 81)
( ) ( )
=
j
j
a P i P
246 PTV AG
Value a
j
is taken from the DOC table (Table 82). 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 82 (see exhibit 17-30 in the HCM 2000 for the full table).
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(a
j
) . The result P(i) = P(a
j
) 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 (C
k
), the adjustment equations are:
a
j
V
j
(volume conflicting approach) P(
a
j)
1 0 0
0 0 1
1 >0 X
j
0 >0 1 - X
j
Table 81: Probability states calculation of degree-of-conflicts
Notes:
If iteration 1, then X
j
= (V
j
h
d
) / 3600
If iteration > 1, then X
j
= (V
j
h
d
) / 3600
Initial value h
d
= 3.2 s
i DOC case (C
k
) Number
vehicles
Approach
opposite
direction
Left
(subject approach)
Right
(subject approach)
L1 L2 L1 L2 L1 L2
1 1 0 0 0 0 0 0 0
2 2 1 1 0 0 0 0 0
3 2 1 0 1 0 0 0 0
4 2 2 1 1 0 0 0 0
64 There are 64 combinations for 4 legs each with 2 lanes.

Table 82: Excerpt from the DOC table for two lanes per approach
247 PTV AG
where
step 3: Calculate adjusted probability
P(i) = P(i) + adjP(i)
where
step 4: Calculate saturation follow-up time
h
si
= h
adj
+ h
base
where
For each DOC case i, the base follow-up time h
base
is taken from a lookup table which is based
on the particular DOC case (1 5) and geometry group (Table 83).
a 0.01 (or 0.00 if no serial correlation)
n number of non-zero cases (i) for each DOC case (at most n = 1 for C
1
, 3 for C
2
, 6 for C
3
, 27 for
C
4
and C
5
)
P(i) adjusted probability for case i
P(i) probability of degree-of-conflicts for case i
adjP(i) probability adjustment factor case i
h
si
saturation follow-up time by DOC case i
h
adj
follow-up time adjustment by lane
h
base
base follow-up time by DOC case i
n / )]
5
C ( P 10 [ a )
5
C ( adjP
n / )]
4
C ( P 6 )
5
C ( P [ a )
4
C ( adjP
n / )]
3
C ( P 3 )
5
C ( P 2 )
4
C ( P [ a )
3
C ( adjP
n / )]
2
C ( P )
5
C ( P 3 )
4
C ( P 2 )
3
C ( P [ a )
2
C ( adjP
n / )]
5
C ( P 4 )
4
C ( P 3 )
3
C ( P 2 )
2
C ( P [ a )
1
C ( adjP
64
38
) i ( P )
5
C ( P
37
11
) i ( P )
4
C ( P
10
5
) i ( P )
3
C ( P
4
2
) i ( P )
2
C ( P
) 1 ( P )
1
C ( P
=
=
+ =
+ + =
+ + + =
=
=
=
=
=
248 PTV AG
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.
Table 84 shows the saturation follow-up time base values.
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.
Number of lanes
Subject
approach
Opposing
approach
Conflicting
approach
Intersection type Geometry group
1 1 1 4 leg or T 1
1 1 2 4 leg or T 2
1 2 1 4 leg or T 3a / 4a
1 2 2 T 3b
1 2 2 4 leg 4b
2 1 - 2 1 - 2 4 leg or T 5
3 1* 1* 4 leg or T 5
3 3 3 4 leg or T 6
Table 83: 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.
DOC case 1 2 3 4 5
Number of
vehicles (Sum of
the [0,1] for the
case)
0 1
2
>=3
1
2
>=3
2
3
4
>=5
3
4
5
>=6
G
e
o
m
e
t
r
y

g
r
o
u
p
1 3.9 4.7 5.8 7.0 9.6
2 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
5 4.5 5.0
6.2
6.4
7.2
7.6
7.8
9.0
9.7
9.7
10.0
11.5
6 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 84: Base values for the saturation follow-up time
249 PTV AG
step 5: Calculate departure follow-up time
where
These five steps are repeated until the departure follow-up time values converge (change is <
0.1). Now, the calculated departure follow-up time h
d
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 = h
d
- m
where
Capacity is calculated as follows: the volume of the subject lane is incremented until the degree
of utilization (v
j
h
d
)/3,600 on the subject lane 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.
where
h
d
departure follow-up time for lane
h
si
saturation follow-up time for each i in I
P(i) adjusted probability for each i in I
i Row of table 1
t service time
h
d
Departure follow-up time
m move up time (2.0 s for geometry groups 1-4 and 2.3 s for groups 5-6)
d
x
mean delay per vehicle for lane x
t ServiceTime
x degree of utilization Vh
d
/ 3,600
h
d
Departure follow-up time
=
I i
si
h ) i ( ' P
d
h
( ) ( ) 5
T 450
x
d
h
2
1 x 1 x T 900 t
x
d +
+ + + =
250 PTV AG
Level of Service is defined as a lookup based on intersection delay (Table 85).
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.
With this method it is assumed, that only one-leg and two-leg approaches exist.
Furthermore it is assumed, that also the intersection itself does not have more than two
lanes.
The calculation process is illustrated by illustration 62.
A 0 10 s
B 10 15 s
C 15 25 s
D 25 35 s
E 35 50 s
F 50 + s
Table 85: Determining the LOS based on the mean delay per vehicle
251 PTV AG
Illustration 62: Calculation process for roundabouts according to HCM 2010
If you use the HCM 2010 operations model for roundabout nodes, the VISUM attributes in
Table 86 will have an effect. Make sure that they are set to realistic values prior to running the
analysis.
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.
Node ICAPHFVolAdj Factor for adjustment of initial volumes to peak volumes.
Volumes are multiplied with both node and turn adjustment
factors.
Turn ICAPHFVolAdj
Link Proportion bypass
volume
Proportion of right turns (left-hand traffic: left turns), which
use a bypass lane for the turn movement.
Lane ICACriticalGap Optionally, you can overwrite the critical gap, used in step 4
The analoguous value of the turn is not used.
Lane ICAFollowUpTime Optionally, you can overwrite the follow-up time, used in step
5 The analoguous value of the turn is not used.
Table 86: Input attributes for roundabout nodes according to HCM 2010
In p u t s
Vol um es
Vo l u m e
In co mi ng l eg s
Con fl icti ng vol ume s
Ti m e g a p s
C ri ti cal g aps
Fol l ow-up t im es
Cap a c i t y
Wa i t i n g t i me
Qu eu e l en g t h
252 PTV AG
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 63 for a roundabout with four
approaches designated with v
1
to v
12
).
Illustration 63: 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 21-
15.
Example
The flow from the south is the sum of turn volumes v
7
+ v
8
+ v
9
. The conflicting flow which
applies to this flow is however the sum v
1
+ v
2
+ v
10
. 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 1130e
Bv
=
253 PTV AG
Here, B equals 0.001 for one-lane and two-lane entry roads to single-lane roundabouts, and for
single-lane approaches to two-lane roundabouts the value is 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 only one conflicting exit lane the value 0.001 is
used, whereas 0.0007 is used if there are two conflicting exit lanes.
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):
where
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 ICAFinalCapacity.
step 4: Wait times
The mean wait time on a lane of an approach arises from the following values:
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.
c capacity in PCU/h
v conflicting flow in PCU/h
gap
c
critical gap in s
gap
f
follow-up time in s
d mean delay in s/PCU
c lane capacity in PCU/h
v lane volume in PCU/h
T observation period in h
c Ae
Bv
=
A
3600
gap
f
------------ =
B
gap
c
gap
f
2
3600
------------------------------------ =
d
3600
c
------------ 900T
v
c
-- 1
v
c
-- 1

2
3600
c
------------
v
c
--
450T
------------------- + + 5 min
v
c
-- 1 , + + =
254 PTV AG
step 5: Queue lengths
The mean queue length on a lane of an approach arises from the following values:
where
The attribute ICAQueueLength 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 87).
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.
illustration 64 shows the calculation process for roundabouts according to the TRL/Kimber
method.
Q
95
95% percentile of queue length in PCU
c lane capacity in PCU/h
v lane volume in PCU/h
T observation period in h
LOS Mean Delay [s / PCU]
A 0 - 10
B >10 - 15
C >15 - 25
D >25 - 35
E >35 - 50
F >50
Table 87: LOS per lane based on the mean delay
Q
95
900T
v
c
-- 1 1
v
c
--

2
3600
c
------------
v
c
--
150T
------------------- + +
3600
c
------------ =
255 PTV AG
Illustration 64: 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 illustration 65, 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.
Inputs
Geometry
Volumes
Volume
Incoming legs
Conflicting volumes
Capaci ty
Waiting time
Queue length
256 PTV AG
Illustration 65: Description of the node geometry for the TRL/Kimber model
Table 88 shows the additional input attributes at links for calculation according to TRL/Kimber.
Name DMRB definition Value
type
Value range
(Default value)
Meaning
ICA inscribed circle
diameter
ICAInscribedCircl
eDiameter (D)
Length 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
Table 88: Input attributes for calculation according to the TRL/Kimber method
257 PTV AG
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 71).
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:
where
ICA approach half width ICAApproachHalf
Width (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.
ICA entry radius ICAEntryRadius
(r)
Length 1 - 1000 m (35
m)
Circle radius which
tangentially approximates to
the outer circle of the
roundabout and the outer
boundary of the approach.
ICA entry angle ICAEntryAngle
()
Integer 0..180 (45) See illustration 65
ICA grade separation ICAGradeSepara
tion (SEP)
Length 0 - 100 m (0 m) Distance between approach
and exit of the same node leg.
For regular roundabouts
specify 0 m. With values > 0
you describe the approaches
at expanded roundabouts,
where the approach is far
away from the exit of the
same leg.
ICAKimberHollis c-factor ICAKimberHollis
C
Doubl
e
0 10 (1.0) In the queue length formula
by Kimber-Hollis, the c-factor
describes the variability of the
inflow
Cap approach capacity in PCU/h
Name DMRB definition Value
type
Value range
(Default value)
Meaning
Table 88: Input attributes for calculation according to the TRL/Kimber method
Cap
k F f q
c
( ) if F f q
c
>
0 else
=
258 PTV AG
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 q
c
+ 14.35 - f q
c
(2.14 - 0.023 q
c
)
where all sizes as above, however Cap and q
c
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).
where
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.
q
c
conflicting flow in PCU/h
k 1 - 0,00347 ( - 30 ) - 0,978 [(1/r) - 0.05]
F 303 x
f 0.21 t (1 + 0.2 x)
t 1 + .5 / (1 + M)
M
e
(D - 60)/10
x v + (e - v) / (1 + 2 S)
S 1.6 (e - v) / L
L expected queue length at the end of the observation period in PC units
approach capacity in PCar units/h
T length of the observation period in h
L
0
initial queue length(in VISUM always 0)
C Variation factor KVKimberHollisC
v approach volume in PCar units/h
= v / = Saturation
A
1 ( ) T ( )
2
1 L
0
( )T 2 1 C ( ) L
0
T + ( ) +
T 1 C +
------------------------------------------------------------------------------------------------------------------------- =
B
4 L
0
T + ( ) T 1 C ( ) L
0
T + ( ) ( )
T 1 C +
----------------------------------------------------------------------------------------------- =
L
1
2
--- A
2
B + A ( ) =
259 PTV AG
step 4: Delays
The mean control-based wait time per approach results from the Kimber and Hollis formula
(Kimber, Hollis 1979), (Kimber, Daly 1986).
where
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 89).
VISUM calculates the LOS of the entire node accordingly, on the basis of the volume weighted
mean delay of all approaches.
d mean permitted delay in the observation period in h
Approach capacity in PCar units/h
T length of the observation period in h
L
0
initial queue length (in VISUM always 0)
C Variation factor KVKimberHollisC
v approach volume in PCar units/h
= v / = Saturation
LOS Mean Delay [s / PCU]
A 0 - 10
B >10 - 15
C >15 - 25
D >25 - 35
E >35 - 50
F >50
Table 89: LOS for calculation according to Kimber based on the mean delay
J
T
2
--- 1 ( )
1
--- L
0
C 2 + ( ) =
K
4
---
T
2
--- 1 ( )
1
2
---TC
L
0
1 +
--------------- 1 C ( ) + =
d
1
2
--- J
2
K + J ( ) =
260 PTV AG
5.5.4 Signal timing optimization.
Within the scope of the intersection capacity analysis using ICA, you can optimize the signal
times for individual signalized junctions in two ways:
Green time optimization (see "Green time optimization for stage-based signal controls" on
page 261) or
Cycle and Green time optimization (see "Signal cycle and green time optimization" on
page 262).
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 262).
5.5.4.1 Data model for SC cycle and green time optimization
The following network object attributes are relevant for signal timing optimization:
Optimization is controlled by the following procedure parameters (components of the
procedure parameters for intersection capacity analysis):
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
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.
SignalCoordinationGro
up
CycleTimeFamily
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
Turns 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
Procedure parameter Data type
(Standard)
Description
Automatic green time
optimization
Boole (False) 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.
261 PTV AG
5.5.4.2 Green time optimization for stage-based signal controls
The predefined cycle time applies as predefined for pure green time optimization. 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:
where
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 StdIntergreen 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 GreenStart and
GreenEnd of the stages.
5.5.4.3 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:
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.
g
i
effective green time for stage i
(v/s)
ci
(v/s)
ci
= ratio of volume v and saturation flow rate s for critical lane group ci in stage i
G
te
total effective green time for cycle
Procedure parameter Data type
(Standard)
Description
( )
( )
te
G
i
ci
s v
ci
s v
i
G
=
262 PTV AG
1. Fictitious stages are generated from the current greentimes of the signal groups.
2. The fictitious stage-based signal control is optimized as above (see "Green time
optimization for stage-based signal controls" on page 261).
3. The signal group green times are read from the optimal stage distribution.
Step 1 - Creating fictitious stages
VISUM first defines set T of all switching points from the attributes GreenStart and GreenEnd
of all signal groups and sorts these in ascending order. For each interval between consecutive
time t
i
and t
i+1
in T generate a stage which contains all signal groups which have been released
during [t
i
; t
i+1
).
Step 2 Optimization of the fictitious stage-based signal control
The fictitious stage-based signal control is optimized as above (see "Green time optimization
for stage-based signal controls" on page 261).
Step 3 - Extracting green times
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.
5.5.4.4 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. The calculation consists of the following steps:
1. Set T of the permitted cycle times at the node is defined. If the procedure parameters
UseCycleTimeFamily = True and if the signal control belongs to a coordination group, only
the cycle times of the cycle time family are permitted. Otherwise, all cycle times (integers in
seconds) in the interval between the node attributes ICAMinCycletimeOpt and
ICAMaxCycletimeOpt are permitted.
2. For each permissible cycle time t from T the following applies:
Specify optimal greentime g*(t) for predefined cycle time t.
Via ICA 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 final values, if the sum of
critical v/s ratios is below or equal to 1. For larger sums it is always t* = max(T). 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.5 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.
263 PTV AG

Example
We will demonstrate the task with the example network displayed in illustration 66.
Illustration 66: Example network for signal coordination
In the network in illustration 66 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 67).
Note: The method does not regard the attributes of the node geometry. Especially the stop
line position per lane is not taken into consideration.
264 PTV AG
Illustration 67: 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 68.
265 PTV AG
Illustration 68: A path through the example network passes SCs at nodes 7003, 8003, 8002 and 9002
This route passes the signalized nodes 7003, 8003, 8002 and 9002. Vehicles which exit node
7003 in direction 8003, when exiting create a platoon, which starts at the beginning of the
green time, thus at second 0. The travel time t
Cur
on the link from 7003 to 8003 is 38 s. Without
taking the platoon resolution into consideration, the peak of the platoon reaches node 8003 at
second 38. The distribution of the actually driven speed by vehicles leads to a resolution of the
original compact platoon (illustration 69).
Illustration 69: Progression quality for approach West at node 8003
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
266 PTV AG
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. Summing up all arrivals results in a total
wait time of 19069 vehicle seconds, correspondent to a mean value of 39.20 s per vehicle. This
is an example for bad coordination.
At node 8002 the situation is much better (illustration 70).
Illustration 70: Progression quality for approach North at node 8002
Again the platoon starts at second 0 and the travel time on the link 8003 - 8002 with t
Cur
= 41
s is similar as before, but the continuing signal group 4 for left turns at node 8002 has a green
time from second 40 to second 75. Here the main part of the platoon enters during green time,
queues are distinctly shorter and the total wait time is only 1608.80 vehicle seconds (in
average 4.37 s per vehicle).
Aim of the signal coordination in this simple example would be to change the offset between
nodes 7003 and 8003 in such a way, that the platoon fully enters 8003 at green. At the same
time, however, to maintain the convenient offset between 8003 and 8002. 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 green waves. 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 269).
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
all SCs in one network. You determine which SCs should be coordinated, by defining signal
267 PTV AG
coordination groups and assigning them SCs (see User Manual, Chpt. 2.39.14, page 539). 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 SC. 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 error 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 q
max
, until the volume per cycle has been exhausted. The following applies:
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 q
max
, VISUM
ignores the excess volume and logs this in the error 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.
where
q
max
1900
PCU
h
------------ N =
q'
t T +
F q
t
1 F ( ) q'
t T 1 +
+ =
268 PTV AG
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 q
t
the number of vehicles arriving at a node in time step t.
Platoon index = with
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.
Vehicles at green = .
This size directly measures how well coordination works. It calculates which part of the volume
passes the node without stopping at the SC.
Platoon ratio =
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.
Platoon ratio PR is the basis for the important ArrivalType size in waiting time calculation
according to HCM.
q
t
the number of vehicles arriving at the end of the path leg in time step t
q
t
the number of vehicles departing at the beginning of the path leg in time step t
F
with specified constants and
T travel time t
Cur
on the path leg
F
1
1 T +
-------------------- =
q
t
avg
t CT
q
t
t CT
------------------------------------------- avg
q
t
t CT
CT
------------------------- =
100
q
t
t GT
q
t
t CT
------------------------
q
t
t GT
q
t
t CT
------------------------

GT
CT
--------

269 PTV AG
ArrivalType =
Queue length queue
t
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
vehicles 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 90.

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 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 90: Input attributes with effect at signal coordination
1 if PR< 0.5
2 if 0.5 <= PR< 0.85
3 if 0.85 <= PR< 1.15
4 if 1.15 <= PR< 1.5
5 if 1.5 <= PR< 2.0
6 if 2.0 <= PR
270 PTV AG
.
Procedure parameters
Alongside the network object attributes, the procedure parameters listed in Table 92 control
signal coordination.
Name Value
type
Value range Meaning
SC Coord Veh 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
period
0 s .. Total wait time [Vehicle seconds]
SC Coord Max Queue
Length
Double 0.0 .. max. number of queued vehicles over all
cycle seconds [Veh]
Table 91: Output attributes for signal coordination results
Note: Attribute SC Coord Arrival Type is marked as the signal coordination with the name
prefix. 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 ArrivalType which
corresponds with the set offset time intervals, first perform the coordination analysis and
copy the SC Coord Arrival Type values to the ICA Arrival Type attribute.
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
(all)
Coordination is only carried out optionally for
selected signal coordination groups.
Demand segments set Set of assigned PrT_DSeg
(all assigned PrT_DSeg)
Path legs are optionally only determined from
the assignment paths selected DSeg.
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
Table 92: Procedure parameters for signal coordination
271 PTV AG
Chapter 5.6: PrT skims
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 93 can
be calculated (see User Manual, Chpt. 5.8, page 933).
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)
When calculating the path leg run time, for
each traversed turn, TravelTimeTurnFac
TravelTimeTurnAttr is summed up
TravelTimeTurnFac Double > 0 (1.0)
TravelTimeMainTurnAttr Numeric main turn
attributes (AddVal1)
When calculating the path leg run time, for
each traversed turn,
TravelTimeMainTurnFac
TravelTimeMainTurnAttr is summed up
TravelTimeMainTurnFac Double > 0 (1.0)
MaxCalculationTime Time period Calculation time for the solution of the
optimization problem is restricted. The best
solution found up to the specified time
limitation, is assigned.
Name Value range (Standard) Meaning
Table 92: Procedure parameters for signal coordination
t0_PrTSys TSys-specific travel time t
0
in unloaded network
tCur_PrTSys TSys-specific travel time t
Cur
in loaded network
AddValue1...3 Sum of AddValue
Trip distance Distance covered from origin to destination
Direct distance Direct distance between origin and destination zone
Speed v0_PrTSys TSys-specific speed v
0
in unloaded network
Speed vCur_PrTSys TSys-specific speed v
Cur
in loaded network
Toll Toll of traversed links
Impedance-PrTSys TSys-specific impedance in unloaded network
AddValue-TSys Sum of TSys-AddValue data
Table 93: PrT skims
272 PTV AG
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 94.
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, two options are differentiated yet
again (distribution of the total demand or distribution per OD pair).
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.
User-defined 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 935)
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 94: Aggregation functions for the skim data calculation
Table 93: PrT skims
273 PTV AG
Chapter 5.8: Blocking back model
Illustration 71: Example network for proportional distribution of the traffic demand
Example: Example: determination of connector capacity for proportional distribution total
traffic (illustration 71)
Zone 1 has proportional distribution
Zone 2 has proportional or absolute distribution
Zone 3 has proportional or absolute distribution
Travel demand from zone 1 to zone 2: 1000 trips
Travel demand from zone 1 to zone 3: 400 trips
Origin demand zone 1: 1400 trips
Connector zone 1 node 1: 40 % proportion
Connector zone 1 node 2: 60 % proportion
Capacity of connector zone 1 node 1: 40 % x 1400 = 560 trips
Capacity of connector zone 1 node 2: 60 % x 1400 = 840 trips
Steep VD function for connectors, for example BPR function with a = 1, b 4, 1
Proportional distribution of each individual relation
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: 40 % 1000 = 400 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 congestion-
related wait times, and dynamic procedures that require long computation times. The
procedure is much faster than any dynamic assignment, requires less memory capacity and

Zone1
1
2
3
Zone2
40 %
60 %
4 Zone3
274 PTV AG
can furthermore deliver information on congestion phenomena. The procedure can be applied
in conjunction with a static assignment in order to estimate queue lengths and wait times in
oversaturated networks, and in contrast to the dynamic-stochastic assignment - is suitable
for networks with > 50,000 links. The procedure requires little additional data for the 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:
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 over a link cannot exceed the links PrT capacity. 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.
275 PTV AG
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 883).
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 preloaded 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.
You can calculate the blocking back model post-processed following an assignment. It
therefore does not influence the route choice.
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 332).
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 been calculated for a demand segment already, 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 t
cur
and t
w
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 integrated in other procedures for calculation, one has to
differentiate between the successively performed procedures (Incremental assignment,
Equilibrium_Lohse and the Stochastic assignment) on the one hand and the balancing
assignments (Equilibrium assignment and TRIBUT procedures) on the other hand. When
calculating the step-by-step procedures, the blocking back model always determines a
corrected volume and delays after the calculation of the volume. From the rectified volume, a
new value is calculated for the current travel time t
i
Cur
in iteration i, to which the wait time t
i
w
is
added.
As new value, the arithmetic mean T
i
of all former t
i
is used, which is also considered in the
subsequent route search.
Here, t
0
Cur
= t
0
and t
0
w
= 0 applies.
t
i
t
akt
i
t
w
i
+ =
T
i
t
k
k 0 =
i
i 1 +
---------------------
t
akt
k
k 0 =
i
t
w
k
+
i 1 +
------------------------------------- = =
276 PTV AG
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 t
w
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 t
Cur
New
, using the corrected volume is necessary, since
the increase of the travel time above the capacity limit is no longer determined by volume-
delay 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, t
Cur
= t
Cur
New
and t
w
= 0 apply in any case. The impedance is unchanged compared to a
conventional assignment in this case.
If the blocking back model is integrated into an equilibrium assignment, 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 t
Cur
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 via a node (sum of all turn volumes) to the node attribute
Capacity PrT. Node capacities are only regarded for traffic flows traversing a minor link
(TModelSpecial = true) in the direction to the node. Traffic flows on major legs therefore
also have an effect on crossing routes via secondary links.
277 PTV AG
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 = TRUE) 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 select TRUE for 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:
Determining the excess congestion factor
Formation of congestion (Phase 1)
Relief of congestion (Phase 2)
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 S, the excess congestion factor
Link
(S) is given by
.
Here, Vol(S) is the link volume resulting from assignment, Cap(S) is the PrT capacity of the link,
and ScalingFactor is the scaling factor from the blocking back model parameters. Furthermore,
q
Preload
(S) is a basic link volume that can be set in the "Procedures" dialog via PrT functions >
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 links and turns in VISUM, the sum of all turn
capacities of a 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 equal the volumes calculated in the assignment, 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.
Link
S ( )
Vol S ( )
Cap S ( ) ScalingFactor q
preloadedVolume
S ( )
--------------------------------------------------------------------------------------------------------------------- =
278 PTV AG
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, turns 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. (This parameter can be
set 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 has already formed or 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, the
current 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:
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/. ( is the excess congestion factor.) The
general process is then as follows:
Loading a volume flow to a route R is performed as follows. Let S
0
, S
1
, ..., S
k
be the generalized
links of a route, i.e. S
0
is the origin connector, S
k
is the destination connector, and the real links
are in between. Now, the traffic from the origin zone flows via S
0
, S
1
, ..., S
k
to the destination
zone, at which the 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(S) be the 'To node' of a link S
and let Turn(S,T) be the turn from S to T for the links S and T. Now, the flow from S
j
to S
j+1
is
limited by the capacity of S
j
, and by the capacity of the 'To node' of S
j
, and by the capacity of
the turn to S
j+1
. (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.) Thus, the maximum flow from S
j
to S
j+1
is as follows:
Vol Original volume resulting from assignment
VolBB (reduced) volume calculated in phase 1
Cap PrT capacity of a link, a turn or a node
C Stocking capacity of a link
Q Queue length of a link (or connector)
P Permeability of a link, describes the share of the flow that can pass existing queues
I ni t i al i ze Vol BB f or al l l i nks, t ur ns, nodes and connect or s by ent er i ng 0.
I ni t i al i ze Q or al l l i nks and connect or s by ent er i ng 0.
For al l l i nks S and connect or s C, l oad Vol ( S) *n/ N or Vol ( C) *n/ N, r espect i vel y.
For j = n+1 t o N
For each demand segment :
For each r out e R of t he demand segment
Load Vol ( R) / N t o r out e R.
279 PTV AG
maxFlow(S
j
, S
j+1
) = min{Cap(S
j
) ScalingFactor - q
Preload
(S
j
),
Cap(toNode(S
j
)) ScalingFactor - q
Preload
(toNode(S
j
)),
Cap(Turn(S
j
, S
j+1
)) ScalingFactor - q
Preload
(Turn(S
j
, S
j+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:
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 C, 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:
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 goes from A to D
and route 2 goes from B to C. Each route has a volume of 200 vehicles. The volume is
distributed to the routes in four iteration steps with 50 vehicles each. 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.
Funct i on Load( R, f l ow) :
For j = 0 t o k- 1
pr opagat i ngFl ow = f l ow
I f Q( S
j
) > 0
pr opagat i ngFl ow: = pr opagat i ngFl ow * Per meabi l i t y( S
j
)
pr opagat i ngFl ow: = mi n( pr opagat i ngFl ow, maxFl ow( S
j
, S
j +1
) )
Vol BB( S
j
) : = Vol BB( S
j
) + pr opagat i ngFl ow
Vol BB( t oNode( S
j
) ) : = Vol BB( t oNode( S
j
) ) + pr opagat i ngFl ow
Vol BB( Tur n( S
j
, S
j +1
) ) : = Vol BB( Tur n( S
j
, S
j +1
) ) + pr opagat i ngFl ow
Q( S
j
) : = Q( S
j
) + ( f l ow - pr opagat i ngFl ow)
Pr opagat e queue backwar ds
Funct i on Pr opagat eQueue( R) :
pr opagat i ngQ = 0
For j = k- 1 t o 1
I f Q( S
j
) > K( S
j
)
pr opagat i ngQ : = Q( S
j
) - K( S
j
)
Q( S
j
) > K( S
j
)
Q( S
j - 1
) : = Q( S
j - 1
) + pr opagat i ngQ
Vol BB( S
j - 1
) = Vol BB( S
j - 1
) - pr opagat i ngQ
Vol BB( t oNode( S
j - 1
) ) : = Vol BB( t oNode( S
j - 1
) ) - pr opagat i ngQ
Vol BB( Tur n( S
j - 1
, S
j
) ) : = Vol BB( Tur n( S
j - 1
, S
j
) ) - pr opagat i ngQ
280 PTV AG
Illustration 72: 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 72).
Illustration 73: 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 73).
281 PTV AG
Since there is now a congestion on the link in the middle, also the vehicles following route 2 get
stuck in the queue (illustration 74).
Route 1: 50 more vehicles are added in interation step 4. As the stocking capacity of the link in
the middle is fully exhausted, vehicles continue to propagate backwards (illustration 75).
282 PTV AG
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 76).
Simulation phase 2: Relief of congestion
During the simulation phase 1, the local queue length of each link and corrected volumes have
been determined. In order to determine a wait time as well, the simulation is continued without
any further traffic flows entering the network until all queue lengths reach zero. Any traffic
passing through the network in phase 2 thus originates from the queues determined in phase
1. In this process, a maximum of the M-th proportion of the capacity is passed on in each
iteration. (M represents the procedure parameter Number of shares for flow distribution in
phase 2.) 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.
Illustration 77: Blocking back model, phase 2, relief of congestion. Initial situation
283 PTV AG
illustration 77 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 78: 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 C = 100. Thus, C / M
= 25 vehicles can flow off in iteration step 1 (illustration 78).
Illustration 79: 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, (C / M = 100); this portion is (C / M) (OrigVol(Route 2) /
OrigVol(link in the middle)) = 100 (200 / 400) = 50 (illustration 79).
284 PTV AG
During iteration step 2, again 25 vehicles flow off via route 1 (illustration 80).
Again, 50 vehicles flow off via route 2 (illustration 81).
285 PTV AG
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 (C / M = 25) (illustration 82).
On the link in the middle, the remaining congestion can flow off via route 2 (illustration 83).
Thus, the flow off in phase 2 works similar to the formation of the congestion in Phase 1; the
only difference is, that origin volumes do no longer arise from connectors, but from the
congested links. 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.
286 PTV AG
In detail, the relief of congestion goes like this: In each iteration step, the Mth portion of the
capacity of links, nodes and turns is available. Thus, the maximum traffic that can flow off of
link S due to the link's capacity, is Cap(S) / M per iteration. To each route R, that traverses link
S, a certain share in the capacity is provided; this share equals the route's share in the original
total link volume, i.e. Vol(R) / Vol(S). For a link S that belongs to a route R, the maximum outflow
of a congestion results from the following formula:
maxOutflow(S) = (Cap(S) / M) (Vol(R) / Vol(S))
Furthermore, the outflow is restricted by the capacity of the To-Node and by the turn capacity.
Let S
0
, S
1
, ..., S
k
again be the generalized links of a route, i.e. S
0
is the origin connector, S
k
is the
destination connector, and the real links are in between. Thus, the maximum flow from S
j
to S
j+1
results as follows:
maxOutflow(S
j
, S
j+1
) = min{(Cap(S
j
) / M) (Vol(R) / Vol(S
j
)),
(Cap(toNode(S
j
)) / M) (Vol(R) / Vol(toNode(S
j
))),
(Cap(Turn(S
j
, S
j+1
)) / M) (Vol(R) / Vol(Turn(S
j
, S
j+1
)))}
The traffic flow that actually flows out comes from the existing queues. For each route R, the
volume originating from the queue on link S
j
is as follows:
sourceVolQ(S
j
) = prevQ(S
j
) (Vol(R) / Vol(S
j
))
The source volume of a link (limited by maxOutflow) flows onto the next link; this volume is
added to the next link's source volume. If maxOutflow is less than the source volume, traffic will
back-up again.Then, the following applies:
As in phase 1, the queue is propagated backwards:
I ni t i al i ze pr evQ wi t h queue l engt hs on l i nks and connect or s af t er phase 1
For j = 1 unt i l ( max. number of i t er at i ons i n Phase 2) or unt i l any pr evQ = 0
For each demand segment
For each r out e R of t he demand segment
Cal cul at e t he congest i on f l ow of f f or R accor di ng t o M and t he
capaci t i es
and t hus obt ai n cur r Q
Cal cul at e wai t t i me
pr evQ: = cur r Q
Funct i on QueueOut f l ow( R, M) :
ar r i vedFl ow = 0
For j = 0 t o k- 1
t ot al Sour ceVol : = sour ceVol Q( S
j
) + ar r i vedFl ow
pr opagat i ngFl ow: = mi n( t ot al Sour ceVol , maxOut f l ow( S
j
, S
j +1
) )
cur r Q( S
j
) : = cur r Q( S
j
) - pr opagat i ngFl ow
ar r i vedFl ow : = pr opagat i ngFl ow
Pr opagat e queue backwar ds
Funct i on Pr opagat eQueue2( R) :
pr opagat i ngQ = 0
For j = k- 1 t o 1
I f Q( S
j
) > K( S
j
)
pr opagat i ngQ : = Q( S
j
) - K( S
j
)
Q( S
j
) > K( S
j
)
Q( S
j - 1
) : = Q( S
j - 1
) + pr opagat i ngQ
287 PTV AG
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. These values together with the queue length after the first
simulation stage are used to form an integral of the overall wait time over the measured queue
length.
illustration 84 shows an example for the display of the integral indicating the overall wait time
over the interpolated measured queue lengths.
Illustration 84: Integral indicating the overall wait time over the interpolated measured queue lengths
This is expressed by the following formula.
with I being the length of the first simulation interval in seconds. The sum extends over the
measured values with Q
S
(0) indicating the queue length Q
S
after the first simulation phase.
This results in a mean wait time per vehicle unit as follows
time
Q
u
e
u
e

l
e
n
g
t
h
[
V
e
h
]
simulation interval I
I/M I/M ...
Q
s
(0)
= Q
s
Q
s
(1)
Q
s
(2)
Q
s
(3)
Q
s
(4)
Q
s
(5)
( ) ( )
+
+ =

M 2
1 i
S
Q i
S
Q
2
S
Q
I
S
W
288 PTV AG
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
These criteria are output in a list as indicators of the goodness of a PrT assignment (see User
Manual, Chpt. 5.7.1, page 932). They are initialized prior to each assignment and stored with
the version file.
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.
Duality 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)
where
Average Excess Cost AEC (Average Excess Cost)
AEC = Excess cost per vehicle
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.
Relative Gap RG
t
w S ,
0 if Vol(S) = 0
W
S
Q
S
------- otherwise
=
TEC Difference between total impedance in the charged network and the hypothetical
impedance resulting if all vehicles took the shortest path per OD pair.
P
ij
Number of routes from i to j
R
ij
min minimum impedance among all routes from i to j
TEC R
r
R
ij
min
[ ] q
r
r P
i j
ij
=
AEC
TEC
n
----------- =
289 PTV AG
Chapter 5.10: Distribution models in the assignment
The objective function of the equilibrium assignment is:
The lower limit X of the objective function F is calculated as follows: X = F - TEC
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 P
i
a
of route i in
terms of the demand by OD pair in the time interval a is determined by including the impedance
R
i
a
in a distribution function and then calculating the utility U
i
a
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:
1. Impedance R
i
a
s converted to the utility U
i
a
of route i in the time interval a.
U
i
a
= f(R
i
a
)
2. From this utility U
i
a
the percentage of demand P
i
a
is calculated (where n is the total number
of routes).
The models reveal differences in the functional relation f of impedance and utility.
Notes: The Relative Gap determines the difference between the current volume in the
network and the equilibrium. It measures the excess cost of vehicles that do not take the
optimum routes yet in proportion to the total impedance in the network.
The calculation of R
ij
min
is based on the current shortest paths. However, these are only
available after a shortest path search. In the assignment procedures, a statistics calculation
follows the shortest path searches.
F R x ( ) x d
0
q
l
l L
=
RG
TEC
X
----------- =
P
i
a
:=
U
i
a
U
j
a

j 1 =
n
---------------------------
290 PTV AG
5.10.1 The Kirchhoff model in the assignment
The utility is as follows:
The percentage of demand is calculated as follows:
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. illustration 85 shows the
parameterization of the Kirchhoff distribution model on the interface.
Illustration 85: 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:
The percentage of demand is as follows:
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.
illustration 86 shows the parameterization of the Logit distribution model on the interface.
U
i
a
R
i
a

=
P
i
a
:=
R
i
a

R
j
a

j
------------------
U
i
a
e
R
i
a
=
P
i
a
:=
e
R
i
a
e
R
j
a
-------------------------
291 PTV AG
Illustration 86: 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 Box-
Cox transformation is explained as follows.
When calculating the utility, b
(
)
(R
i
a
) is now included in the Logit model instead of R
i
a
, thus
results.
The percentage P
i
a
of the route i in terms of the demand for time interval a is then calculated
as follows:
The importance of the Box-Cox model is illustrated by the two special cases below.
= 0 (leads to the Kirchhoff distribution)
With these parameter settings, b
(0)
(R
i
a
) = log(R
i
a
) applies, thus the following applies to the
choice:
This is precisely the Kirchhoff model.
= 1 (leads to the Logit distribution)
( )
( )
( )
=
=
0
1
0 log
:

if
x
if x
x b
U
i
a
e
b
( )
R
i
a
( )
=
P
i
a
:=
e
b
( )
R
i
a
( )
e
b
( )
R
j
a
( )
j
--------------------------------------
P
i
a e
R
i
a
( ) log
e
R
j
a
( ) log
j
-----------------------------------
R
i
a

R
j
a

j
------------------ = =
292 PTV AG
With these parameter settings, b(
1
)(R
i
a
) = (R
i
a
-1) applies, thus the following applies to the
choice:
This is identical to the Logit distribution.
illustration 87 shows the parameterization of the Box-Cox distribution model on the interface.
Illustration 87: 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.
applies.
Here, R
min
a
:= min
j
R
j
a
is the smallest occurring impedance, and is again a parameter to
control the impedance sensitivity. When calibrating, do not forget that is squared.
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.
illustration 88 shows the parameterization of the Lohse distribution model on the interface.
P
i
a e
R
i
a
1 ( )
e
R
j
a
1 ( )
j
-----------------------------------
e
R
i
a
e
R
j
a
------------------------- = =
P
i
a
:=
e

R
i
a
R
min
a
---------- 1

e

R
j
a
R
mi n
a
---------- 1

----------------------------------------------
293 PTV AG
Illustration 88: 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
R
min
a
. The calculation can be calibrated in more detail when using three additional parameters
, and .
The following approach applies:
The following therefore applies:
is calculated according to the following formula:
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.
The following example illustrates the effect of the distribution model Lohse with variable beta.
illustration 89 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.
U
i
a
e

R
i
a
R
mi n
a
---------- 1

=
P
i
a
:=
e

R
i
a
R
min
a
---------- 1

e

R
j
a
R
mi n
a
---------- 1

----------------------------------------------

1 e
R
mi n
a
( )
+
------------------------------------- =
294 PTV AG
Illustration 89: Distribution with variable beta according to the modified Kirchhoff rule
(please refer to Schnabel / Lohse)
The parameters in illustration 89 are described in Table 95.
illustration 90 shows the parameterization of the Lohse distribution model with variable beta on
the interface.
Illustration 90: Parameterization of the Lohse distribution model with variable Beta

R
min
a
10 0.800 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 95: Parameters for the distribution with variable beta in illustration 89
295 PTV AG
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. Table 96 to Table 98 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 99.
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 96), or
105 and 110 minutes (Table 97). 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 98, 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.
No. R Kirchhoff Logit Box-Cox Lohse
1 5 94 % 78 % 86 % 100 %
2 10 6 % 22 % 14 % 0 %
Table 96: Distribution to two alternatives with the impedances 5 and 10
1 105 55 % 78 % 62 % 51 %
2 110 45 % 22 % 38 % 49 %
Table 97: Distribution for two alternatives with impedance 105 and 110
296 PTV AG
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 %).
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.
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
Table 100 shows how the incremental procedure works on the example network (see
"Example network for the PrT assignment procedures" on page 197). The 2000 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 car trips, that is, with 1,000 car trips.
1 50 94 % 100 % 100 % 100 %
2 100 6 % 0 % 0 % 0 %
Table 98: Distribution for two alternatives with impedance 50 and 100
Kirchhoff = 4
Logit = 0.25
Box-Cox = 1, = 0.5
Lohse = 4
Table 99: Model parameters
297 PTV AG
Chapter 5.11: Incremental assignment
Iteration step 2
The shortest route after the first iteration step 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 car trips, that is, with 500 car trips, and now has
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 t
Cur
, and that current travel
time in turn results from the BPR function with a=1, b=2 and c=1.
LinkNo Type Length [m] v0 [km/h] Capacity t0 [min]
1 20 5000 100 1200 03:00
2 20 5000 100 1200 03:00
3 20 5000 100 1200 03:00
5 20 5000 100 1200 03:00
6 20 5000 100 1200 03:00
7 20 5000 100 1200 03:00
8 30 16000 80 800 12:00
9 30 5000 80 800 03:45
10 40 10000 60 500 10:00
11 40 5000 60 500 05:00
Route Links of the route Length [m] t0 [min]
1 1+8+9 26000 18:45
2 1+2+3+5+6+7 30000 18:00
3 10+11+5+6+7 30000 24:00
LinkNo Volume tCur Volume tCur Volume tCur
Step 1 (50%) Step 2 (25%) Step 3 (25%)
1 1000 05:05 1500 07:41 2000 11:20
2 1000 05:05 1000 05:05 1000 05:05
3 1000 05:05 1000 05:05 1000 05:05
5 1000 05:05 1000 05:05 1000 05:05
6 1000 05:05 1000 05:05 1000 05:05
7 1000 05:05 1000 05:05 1000 05:05
298 PTV AG
5.11.2 Procedure of the incremental assignment
illustration 91 shows the procedure of an incremental assignment.
8 0 12:00 500 16:41 1000 30:45
9 0 03:45 500 05:13 1000 09:37
10 0 10:00 0 10:00 0 10:00
11 0 05:00 0 05:00 0 05:00
Route Volume tCur Volume tCur Volume tCur
Step 1 (50%) Step 2 (25%) Step 3 (25%)
1 0 20:50 500 29:35 1000 51:42
2 1000 30:30 1000 33:06 1000 36:45
3 0 30:15 0 30:15 0 30:15
Table 100: Example of the incremental assignment (BPR function a=1, b=2, R=tCur)
LinkNo Volume tCur Volume tCur Volume tCur
299 PTV AG
Chapter 5.11: Incremental assignment
Illustration 91: 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 1227) or in the network editor (see User Manual, Chpt. 12.2,
page 1253) . Table 101 gives an overview of which input attributes have to be maintained.
Table 102 lists the output attributes which store the results of the procedure.
Demand matrix F
Number of iteration steps N
Demand proportion P
n
for each iteration step n = 1, N
Input
n = 0
Volume q
0
= 0 or basic volume
Determination of impedance R
n
of all network objects with
t he corresponding impedance function.
Determination of the best route for all relations based on
impedance R
n.
Assignment of travel demand which results from P
n
onto
network objects which are part of the best route.
q
n+1
= q
n
+ P
n
F
Determination of impedance R
n
of all network objects with
t he corresponding impedance function.
n = n +1
n = N ?
Impedance
determination
Route search
Query
End
yes
no
Volume
300 PTV AG
Table 101: Input attributes for the incremental assignment
The abbreviations have the following meanings:
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
301 PTV AG
Chapter 5.12: Equilibrium assignment
Table 102: 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.
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.
5.12 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
302 PTV AG
fundamental methodical advantage of the equilibrium assignment - with quite general
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 103 and Table 104.
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 103).
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 104).
5.12.1 Evaluation of the equilibrium assignment
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 342
and "Dynamic stochastic assignment" on page 396) the equilibrium assignment provides
Route Links Volume tCur [min] Volume tCur
1 1+8+9 736 38:19 470:05:53
2 1+2+3+5+6+7 995 38:21 636:01:21
3 10+11+5+6+7 269 38:20 171:50:02
Total 2000 1277:57:17
Table 103: Calculation of the user optimum for the example network
Route Links Volume tCur [min] Volume tCur
1 1+8+9 734 37:43 461:46:27
2 1+2+3+5+6+7 919 37:13 569:58:45
3 10+11+5+6+7 347 41:13 238:11:24
Total 2000 1269:56:36
Table 104: Calculation of the system optimum for the example network
303 PTV AG
distinct network volumes. Convergence parameter such as Duality Gap or Relative Gap are
more objective termination criteria than for example the number of calculated iterations.
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 105 and illustration 92. 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 189). 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 t
Cur
. The current
travel time t
Cur
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.
Traffic demand between village A and city X consists of 2000 car trips during the 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.
304 PTV AG
Illustration 92: Example network for the equilibrium assignment
As a result, the assignment provides values from Table 106 for the three routes (PrT paths).
LinkN
o
From
Node
1 10 11 20 Federal road 5000 1200 100
2 11 20 20 Federal road 5000 1200 100
3 20 21 20 Federal road 5000 1200 100
4 20 40 90 Rail track 10000 0 0
5 21 30 20 Federal road 5000 1200 100
6 30 31 20 Federal road 5000 1200 100
7 31 40 20 Federal road 5000 1200 100
8 11 41 30 Country road 16000 800 80
9 40 41 30 Country road 5000 800 80
10 10 12 40 Other roads 10000 500 60
11 12 21 40 Other roads 5000 500 60
Table 105: Example network for the equilibrium assignment
Route tCur Impedance Volume(AP)
1 46min 39s 2798 1157.488
2 46min 34s 2794 618.079
3 46min 12s 2772 224.432
Table 106: Assignment results for the three PrT paths

11
21
20
10
12
41
40
31 30
village A
city X
1
2 9
6 5
8
11
7 3
10
305 PTV AG
The most important assignment results for the links are displayed in Table 107.
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
page 1253) . The Table 108 gives an overview of which input attributes have to be maintained.
Li
nk
tCur Impedance Volume(AP) Saturation PrT
(AP)
VehicleHr(tCur) VehKmTravelle
d PrT
1 11min 40s 700 1908 170 370h 54min 19s 9537.839
2 5min 47s 347 1157 96 111h 43min 15s 5787.442
3 5min 47s 347 1157 96 111h 43min 15s 5787.442
5 7min 48s 468 1450 126 188h 29min 38s 7249.603
6 7min 48s 468 1450 126 188h 29min 38s 7249.603
7 7min 48s 468 1450 126 188h 29min 38s 7249.603
8 26min 35s 1595 750 110 332h 23min 38s 12001.270
9 8min 19s 499 750 110 103h 52min 23s 3750.397
10 15min 12s 912 292 72 74h 3min 56s 2924.321
11 7min 36s 456 292 72 37h 1min 58s 1462.161
Table 107: Assignment result at the links
306 PTV AG
Table 108: Input attributes of the equilibrium assignment
x1 Toll PrTSys has to be inserted manually in the impedance function
0 Generally possible, however not recommended
307 PTV AG
Table 109: 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.
The following applies.
E the set of all edges in a network and a one of these edges
min! R
a
x ( ) x d
0
q
a
a E
q
ijr
0 ijr , >
q
ijr
r
q
ij
= ij ,
q
ijr
ijr:a P
ijr
q
a
= a ,
q
a
q
a
a E
u
-
a E
u
+
q
iu
q
uj
j
D
u
O
u
= = u ,
308 PTV AG
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 93 will be made.
q
a
volume of object a
R
a
(x) the impedance of object a with volume x (monotonically increasing in x)
q
ij
the total demand (number of trips) from zone i to zone j
q
ijr
volume of route r from zone i to zone j
P
ijr
route r from zone i to zone j
E
+
u
the set of the incoming edges at node u
E
-
u
the set of the outgoing edges at node u
D
u
destination traffic at node u
O
u
origin traffic at node u
309 PTV AG
Illustration 93: 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 relative gap can be used as termination condition (see User
Manual, Chpt. 5.6.2.2, page 891).
Loaded network (starting solution) wit h loaded routes r
Maximum number of iterat ion steps N
Maximum absolute deviation of impedance E
abs
Maximum relative deviation of impedance E
rel
Input
n = 0
Balance the volumes of all routes r for all OD pairs ij so
t hat t he impedance R
rij
of the rout es is:
| min. R
ij
max. R
ij
|< E
abs
or
max. R
ij
/ min. R
ij
< 1 + E
rel
Determination of the best routes f or all relations i-j based
on impedance R
(n)
.
End
n = n +1
New routes f ound and
n < N and
relative gap > max. permitted relative gap?
Network
balancing
Route search
Query
yes
no
310 PTV AG
Network balancing
The procedure of the network balancing is displayed in illustration 94.
Illustration 94: 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:
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. relative gap is reached or undercut.
Volume q
r
of each route r,
I mpedance R
r
of each route r,
Maximum absolute deviation of impedance E
abs
Maximum relative deviation of impedance E
r el
Input
Select two routes:
Rout e r
1
: Rout e with minimal impedance R
1
Rout e r
2
: Rout e with maximum impedance R
2
Update impedance of all network objects whose volume
has changed.
Network balancing completed
I s t he following condition fulfilled for the route with the
minimum impedance R
1,
and the route with the maximum
impedance R
2
?
| R
1
R
2
| < E
abs
or
R
2
/ R
1
< 1 + E
r el
Updat e
impedance
Pair balancing
Query
End
yes
no
Route search
Balance the volume of rout es r
1
and r
2
in such a way that
t he impedance of the routes is:
| R
1
R
2
|< E
abs
or
1 E
rel
< R
1
/ R
2
< 1 + E
r el
I f the volume of route r
1
or r
2
is 0 after balancing, delete
route.
311 PTV AG
In case of an equilibrium assignment with blocking back model the maximum deviation was
reached or undercut (see "Blocking back model" on page 273). 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.
5.12.5 Calculation example for the equilibrium assignment
Route Volume tCur [min]
Starting solution 1 1000 51:42
Routes 1 + 2 are known 2 1000 36:45
3 0 30:15
Network balancing 0 1 776 41:54
Routes 1 + 2 2 1224 41:56
3 0 33:22
1. Iteration step: route search finds route 3
Routes 1 + 3 2 1224 42:58
3 127 36:23
Max. imp. route = 2, Min. imp. route = 3
Routes 2 + 3 2 1067 40:17
3 284 40:15
Routes 1 + 2 2 982 38:10
3 277 38:51
Routes 1 + 3 2 982 38:07
3 277 38:31
Routes 2 + 3 2 990 38:14
3 269 38:15
Routes 1 + 2 2 995 38:21
3 269 38:20
Table 110: Example equilibrium procedure (BPR function a=1, b=2)
312 PTV AG
Table 110 shows how the equilibrium procedure works on the example network (see "Example
network for the PrT assignment procedures" on page 197). The volume determined with the
incremental procedure is used here as the initial solution (see "Example of the incremental
assignment" on page 296). 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. This is guaranteed with a volume of 776
and 1224 vehicles for route 1 and route 2.
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.
313 PTV AG
Chapter 5.13: Linear User Cost Equilibrium (LUCE)
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:
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:
f
ij
=
k
K

ij
k
F
k
The travel demand between origin oZ and destination Z must be equal to the sum of the
flows on the paths that connect them:
Kod
F
k
= D
od
Moreover, all path flows must satisfy non-negativity constraints.
As usual, we assume additive path costs, i.e. the impendence C
k
associated by users to a
given path k is the sum of the costs on the arcs that belong to it:
C
k
=
ij
A

ij
k
c
ij
(6)
By definition, the minimum cost to reach destination dZ from node iN is the cost of any
shortest path that connects them:
I
m
p
= min{C
k
: kK
id
} (7)
f
ij
Total flow on arc ijA, generic element of the (|A|1) vector f
c
ij
Cost of arc ijA, generic element of the (|A|1) vector c
c
ij
( f
ij
) Cost function of arc ijA
Z N Set of the zone centroids
D
od Demand flow between origin oZ and destination dZ, generic element of the (|Z|
2
1) vector
D, that is the demand matrix in row major order
K
id
Set of the acyclic paths between node iN and destination dZ
C K =
o
Z

d
Z
K
od
is the set of paths available to road users
ij
k

ij
k
= 1, if arc A belongs to path k, and 0, otherwise for K, this is the generic element of
the (|A||K|) matrix
od
k

od
k
is 1, if path kK connects origin oZ to destination dZ (i.e. kK
od
), and 0, otherwise
this is the generic element of the (|Z|
2
|K|) matrix
F
k
Flow on path kK, generic element of the (|K|1) vector F
C
k
The cost of path k for kK this is the generic element of the (|K|1) vector C
W
i
d Minimum cost to reach destination dZ from node iN
Set of real numbers
|S| Cardinality of the generic set S
314 PTV AG
In this case, the traffic assignment problem can be formalized through the following program:
(8)
where
To ensure the existence and uniqueness of the solution to problem (8) we assume that:
c
ij
(f
ij
) is non-negative, continuous, strictly monotone increasing;
K
od
is non-empty;
D
od
is non-negative.
Problem (8), which is convex, can also be expressed in terms of path flows as follows:
(9)
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.
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 Z:
F
k
(C
k
- W
o
d
) = 0, kK
od
(10.1)
C
k
W
o
d
, kK
od
(10.2)
F
k
0, kK
od
(10.3)
Kod
F
k
= D
od
(10.4)
Based on (10.1) to (10.4)
all used paths (F
k
> 0) have minimum cost (C
k
= W
o
d
);
any unused path (F
k
= 0) has not a lower cost (C
k
W
o
d
).
We have a user equilibrium if conditions (10.1) to (10.4) hold jointly for each OD couple, while
considering that each path cost C
k
is a function (potentially) of all the path flows F through the
arc cost function:
C
k
=
ijA

ij
k
c
ij
(
kK

ij
k
F
k
), in compact form C = DT c(DF)
Since the gradient of (F) is C =
T
c(F), by linearizing the objective function of problem (9)
at a given a point F, for X F we obtain:
{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
min (f) c
ij
x ( ) x: f d
0
f
ij
ij A
=

min (F) c
ij
x ( ) x: F d
f 0 =
ij
k
F
k
k K
ij A
=

315 PTV AG
(X) = F(F) + CT(X-F) + o(||X-F||). (11)
From equation (11) we recognize that a direction E-F is descent if and only if:
C
T
(E-F) < 0. (12)
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 C
T
E < C
T
F, where C =
T
c(F). The
necessity derives from the convexity of the problem, since in this case at any point X such that
C
T
(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 C
1
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.5
k
, for any non-negative integer k, such that
(0.5
k
)/ < 0. (13)
This method requires to compute the directional derivative of the objective function:
()/ = [c((F+(E-F)))]
T
[(E-F)] , (14)
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 c
1
( f
1
) and c
2
( f
2
), respectively.
At the current flow pattern f

= (D/2, D/2), it is c
1
< c
2
(see illustration 95), 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. c
a
+ c
a
( f
a
)/f
a
( f
a
-
f
a
) , 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.
316 PTV AG
Illustration 95: 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) he 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:
For the flow pattern 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
f
ij
d current flow on arc ijA directed to destination dZ
By construction it is f
ij
d
= 0 for each jFSB(i, d);
moreover it clearly is: f
ij
=
dZ
f
ij
d
f
i
d
=
j
FSB(i, d)
f
ij
d current flow leaving node iN to destination dZ
y
ij
d
y
ij
d
= f
ij
d
/ f
i
d
current flow proportion on arc ijA directed to destination dZ, if
f
i
d
> 0, y
ij
d
= 0 else
e
ij
d descent direction, in terms of flow on arc ijA directed to destination dZ
317 PTV AG
For the cost pattern we will use the following notation:
The average cost C
i
d
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 f
i
d
> 0 , then C
i
d
=
j
FSB
(i
,
d
) yij
d

(
c
ij + C
j
d
), else (15.1)
C
i
d
= min{c
ij
+ C
j
d
: jFSB(i, d)}, (15.2)
as if drivers utilize paths accordingly with the current flow proportions. In the following we
assume that the cost function c
ij
( f
ij
) is continuously differentiable for each arc A:
g
ij
= c
ij
(f
ij
) / f
ij
(16)
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 f
i
d
> 0, then G
i
d
= C
i
d
/ f
i
d
=
j
FSB
(i
,
d
)

yijd
2

(
g
ij + G
j
d
), else (17.1)
G
i
d
=
j
FSB(i, d)
[C
i
d
= c
ij
+ C
j
d
] (g
ij
+ G
j
d
) /
j
FSB(i, d)
[C
i
d
= c
ij
+ C
j
d
], (17.2)
where the derivatives g
ij
+ G
j
d
are scaled by the share y
ij
d
of f
i
d
utilizing arc ij and then
passing through node j, that jointly with the flow proportion involved in the averaging yields the
square
y
ij
d

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 from C
d
d
= G
d
d
= 0.
We now address the local user equilibrium for the e
i
d
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:
v
ij
d
(e
ij
d
) = (c
ij
+ C
j
d
) + (g
ij
+ G
j
d
) (e
ij
d
- y
ij
d
e
i
d
), (18)
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:
e
ij
d
[v
ij
d
(e
ij
d
) - V
i
d
] = 0, jFSB(i, d), (19.1)
v
ij
d
(e
ij
d
) V
i
d
, jFSB(i, d), (19.2)
e
ij
d
0, jFSB(i, d), (19.3)
e
i
d descent direction, in terms of flow leaving node iN directed to destination dZ
e
ij
d
= e
ij
d
/ e
i
d descent direction, in terms of flow proportion on arc ijA directed to destination
dZ
C
i
d average cost to reach destination dZ from node iN
g
ij
Cost derivative of arc ijA
G
i
d Derivative of the average cost to reach destination dZ from node iN.
318 PTV AG
FSB(i, d)
e
ij
d
= e
i
d
, (19.4)
where we denote:
If e
i
d
= 0, the solution to the above problem is trivially: e
ij
d
= 0, for each jFSB(i, d). Consider
then the case where e
i
d
> 0. To improve readability, problem (19.1) to (19.4) can be rewritten
as:
x
j
(a
j
+ b
j
x
j
- v) = 0, jJ, (20.1)
a
j
+ b
j
x
j
v, jJ, (20.2)
x
j
0, jJ, (20.3)
j
x
j
= 1, (20.4)
where:
Applying the usual Beckmann approach we can reformulate the equilibrium problem (20.1) to
(20.4) as the following quadratic program:
min{
j
J

0
xj
(a
j
+ b
j
x) dx: xX} = min{
j
J
a
j
x
j
+ 0.5 b
j
x
j
2
: xX} , (21)
where X is the convex set of all vectors satisfying the feasibility conditions (20.3) and (20.4).
The gradient of the objective function is a vector with generic entry a
j
+ b
j
x
j
, and then the
Hessian of the objective function is a diagonal matrix with generic entry b
j
. Therefore, if all
entries b
j
are strictly positive, the Hessian is positive definite and problem (21) has a unique
solution. In order to ensure such a desirable property we assume without loss of generality that
the derivates g
ij
are strictly positive for all arcs ijA. Since the arc cost functions are strictly
monotone increasing, g
ij
can be zero only if also f
ij
d
is zero. Therefore, at the equilibrium b
j
=
0 implies x
j
= 0. In practice we will substitute any g
ij
= 0 with a small .
To solve problem (20.1) to (20.4) we propose the following simple method. In order to satisfy
condition (20.1), either it is x
j
= 0, and in this case condition (20.2) requires a
j
v, or it is a
j
+ b
j
x
j
= v. Let J
0
J be the set of alternatives with zero flow, that is J
0
= { jJ: x
j
= 0}. For any
given J
0
the solution is immediate, since from (20.4) it is
j
J
(v - a
j
) / b
j
= 1; therefore we have:
v = (1 +
j
J\J0
a
j
/ b
j
) / (
j
J\J0
1 / b
j
) , (22.1)
x
j
= (v - a
j
) / b
j
, jJ\J
0
, (22.2)
x
j
= 0 , jJ
0
. (22.3)
V
i
d local equilibrium cost to reach destination dZ from node iN;
v
ij
d Cost of the local alternative jFSB(i, d) to reach destination dZ from node iN via j.
J {(i, j, d): jFSB(i, d)}
a
j (c
ij
+ C
j
d
) - (g
ij
+ G
j
d
) e
i
d
y
ij
d
b
j (g
ij
+ G
j
d
) e
i
d
x
j e
ij
d
/ e
i
d
V
V
i
d
319 PTV AG
The flow proportions provided by (22.1) to (22.3) implicitly satisfy (20.4). But to state that the
chosen J
0
yields the solution of problem (20.1) to (20.4), we still must ensure the following
conditions: a
j
< v, for each jJ\J
0
(as required by (20.3), since x
j
= (v - a
j
) / b
j
> 0), and a
j
v, for
each jJ
0
(as required by (20.2), since x
j
= 0). This implies that at the solution the value of v
resulting from (22.1) must partition the set J into two sub-sets: the set J
0
, made up by the
alternatives j such that a
j
v; and its complement J\J
0
, made up by the alternatives j such that
a
j
< v.
At a first glance the problem to determine the set J
0
of alternatives with zero flow may seem to
be combinatorial. However, this is not the case. The equation (22.1) can be rewritten as a
recursive formula. It then shows the effect of removing an alternative k from the set J
0
:
v[J
0
\{k}] = (v[J
0
]
j
J\J0
1 / b
j
+ a
k
/ b
k
) / (
j
J\J0
1 / b
j
+ 1 / b
k
) . (23)
The right hand side of (23) can be interpreted as an average between v[J
0
] and a
k
with the
positive weights
j
J\J0
1 / b
j
and 1 / b
k
. Therefore, the local equilibrium cost increases by
removing from J
0
any alternative kJ\J
0
, for which a
k
is higher than the current value v[J
0
]. Vice
versa it decreases by adding such alternatives to J
0
. Consequently, the correct partition set J
0
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 (22.2) yields a negative flow proportion.
5.13.3 Descent direction
To obtain a complete pattern of arc flows e
d
for a given destination dZ consistent with the local
user equilibrium we simply have to solve problem (19.1) to (19.4) at each node i{d}
proceeding in topological order, where the node flow is computed as follows:
e
i
d
=
j
BSB(i, d)
e
ji
d
+ D
id
(24)
We have shown that a given direction is descent if, and only if (12) applies (see "Mathematical
formulation and theoretical framework" on page 313). In terms of arc flows directed to
destination dZ, the following results:
ijA
c
ij
(e
ij
d
- f
ij
d
) < 0, (25)
expressing that the shift of flow from f
d
to e
d
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.
320 PTV AG
Illustration 96: Numerical example of the procedure to obtain the descent direction
The arc cost function is c
ij
= T
ij
+ Q
ij

f
ij
2
, so that its derivative is g
ij
= 2 Q
ij
fij .
There is only one destination d = 4, and two origins with travel demand D
14
= 9 and
D
24 = 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 f
ij
= f
ij
d
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 C
i
d
and its derivative G
i
d
iteratively stating from the
destination, where C
d
d
= G
d
d
= 0, and proceeding in reverse topological order. To this aim we
apply the formulas:
C
i
d
=
j
FSB(i, d)
y
ij
d
(c
ij
+ C
j
d
), G
i
d
=
j
FSB(i, d)
y
ij
d

2
(g
ij
+ Gj
d
)
.
While the computation for node 3 is trivial, since its forward star is a singleton, for node 2 we
have:
C
2
4
=
y
23
4

(
c
23
+
C
3
4
) +
y
24
4 (c24 + C44) = 0.5 (21 + 52) + 0.5 (42 + 0) = 57.5,
G
2
4
=
y
23
4

2
(
g
23
+
G
3
4
) +
y
24
4

2
(
g24 + G44) = 0.52 (8 + 14) + 0.52 (16 + 0) = 9.5,
and for node 1 it is:
C
3
4
= y
13
4
(c
13
+ C
3
4
) + y
12
4
(c
12
+ C
2
4
) = 0.33 (29 + 52) + 0.66 (41 + 57.5) = 92.7,
G
3
4
= y
13
4 2
(g
13
+ G
3
4
) + y
12
4 2
(g
12
+ G
2
4
) = 0.33
2
(12 + 14) + 0.66
2
(12 + 9.5) = 12.4.
321 PTV AG
Illustration 97: Numerical example of the procedure to obtain the descent direction
Now we can compute for each node i the node flows e
i
d
and the arc flows e
ij
d
iteratively by
proceeding in topological order.
To this aim we shall focus on the local route choice of the e
i
d
users, whose available
alternatives are the arcs of the bush exiting from node i. To each travel alternative we
associate the cost function:
v
ij
(e
ij
d
) = (c
ij
+ C
j
d
) + (g
ij
+ G
j
d
) (e
ij
d
- y
ij
d
e
i
d
),
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:
V
i
d
= (1 +
j
J
a
ij
d
/ b
ij
d
) / (
j
J
1 / b
ij
d
), e
ij
d
= e
i
d
(V
i
d
- a
ij
d
) / b
ij
d
,
where: a
ij
d
= (c
ij
+ C
j
d
) - (g
ij
+ G
j
d
) e
i
d
y
ij
d
, b
ij
d
= (g
ij
+ G
j
d
) e
i
d
. J is set initially to the forward
star FSB(i, d); if some e
ij
d
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 e
1
4
= D
14
= 6:
a
13
4
= (c
13
+ C
3
4
) - (g
13
+ G
3
4
) e
1
4
y
13
4
= (29 + 52) - (12 + 14) 9 0.33 = 3,
a
12
4
= (c
12
+ C
2
4
) - (g
12
+ G
2
4
) e
1
4
y
12
4
= (41 + 57.5) - (12 + 9.5) 9 0.66 = -30.5,
b
13
4
= (g
13
+ G
3
4
) e
1
4
= (29 + 14) 9 = 387.
b
12
4
= (g
12
+ G
2
4
) e
1
4
= (41 + 9.5) 9 = 454.5,
V
1
4
= (1 + a
13
4
/b
13
4
+ a
12
4
/b
12
4
) / (1/b
13
4
+1/b
12
4
) = (1+ 3/387-30.5/454.5) / (1/387+1/454.5) = 196.6,
e
13
4
= e
1
4
(V
1
4
- a
13
4
) / b
13
4
= 9 (196.6 - 3) / 387 = 4.5,
e
12
4
= e
1
4
(V
1
4
- a
12
4
) / b
12
4
= 9 (196.6 + 30.5) / 454.5 = 4.5.
Then we go on with node 2, whose node flow is e
2
4
= e
12
4
+ D
24
= 4.50 + 2 = 6.5:
a
23
4
= (c
23
+ C
3
4
) - (g
23
+ G
3
4
) e
2
4
y
23
4
= (21 + 52) - (8 + 14) 6.5 0.5 = 1.5,
a
24
4
= (c
24
+ C
4
4
) - (g
24
+ G
4
4
) e
2
4
y
24
4
= (42 + 0) - (16 + 0) 6.5 0.5 = -10,
322 PTV AG
b
23
4
= (g
23
+ G
3
4
) e
1
4
= (8 + 14) 6.5 = 143.
b
24
4
= (g
24
+ G
4
4
) e
1
4
= (16 + 0) 6.5 = 104.
V
2
4
= (1 + a
23
4
/b
23
4
+ a
24
4
/b
24
4
) / (1/b
23
4
+1/b
24
4
) = (1 +1.5/143 -10/104) / (1/143+1/104) = 55.1,
e
23
4
= e
2
4
(V
2
4
- a
23
4
) / b
23
4
= 6.5 (55.1 - 1.5) / 143 = 2.43,
e
24
4
= e
2
4
(V
2
4
- a
24
4
) / b
24
4
= 6.5 (55.1 + 10) / 104 = 4.07.
Finally we consider node 3, whose node flow is e
3
4
=
e
13
4
+
e
23
4
+ D34 = 4.5 + 2.43 + 0 = 6.93:
Since there is only one alternative, e
34
4
=
e
3
4 = 6.93 results immediately. Only for completeness
we compute V
3
4
as follows:
V
3
4
= (c
34
+ C
4
4
) + (g
34
+ G
4
4
) (e
34
4
- e
34
y
34
4
) = (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:
ij
A
f
ij
d
c
ij
= 949 >
ij
A
e
ij
d
c
ij
= 897.
illustration 96 represents the AON assignment to shortest paths (marked by *). illustration 97
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 i ni t i al i ze t he sol ut i on f l ows t o zer o
for k = 1 to n per f or mn i t er at i ons
for each dZ f or each dest i nat i on d
for each ijA comput e ar c cost s and t hei r der i vat i ves
c
ij
= c
ij
( f
ij
)
g
ij
= max{c
ij
( f
ij
)/f
ij
, }
if f
i
d
> 0 then y
ij
d
= f
ij
d
/ f
i
d
else y
ij
d
= 0
B(d) =B(B(d), c, f) i ni t i al i ze or modi f y t he cur r ent bush
C
d
d
= 0 t he aver age cost of t he dest i nat i on i s zer o
G
d
d
= 0 so i t s der i vat i ve
for each i:ijB(d) in reverse topological order f or each node i d i n t he bush
if f
i
d
> 0 then
C
i
d
=
jFSB(i, d)
y
ij
d
(c
ij
+ C
j
d
) comput e t he node aver age cost t o d
G
i
d
=
jFSB(i, d)
y
ij
d

2
(g
ij
+ G
j
d
) and i t s der i vat i ve
else
C
i
d
= mi n{c
ij
+ C
j
d
: jFSB(i, d)}
G
i
d
=
jFSB(i, d)
[C
i
d
= c
ij
+ C
j
d
] (g
ij
+ G
j
d
) /
jFSB(i, d)
[C
i
d
= c
ij
+ C
j
d
],
e
d
= 0 r eset t he ar c and node f l ows t o d
for each oZ l oad on t he or i gi ns t he demand t o d
e
o
d
= D
od
for each i:ijB(d) in topological order f or each node i d i n t he bush
J = FSB(i, d) i ni t i al i ze t he set of ar cs wi t h posi t i ve f l ow
= 0
until = 1 do
= 1
323 PTV AG
V
i
d
= [e
i
d
+
jJ
(c
ij
+ C
j
d
) / (g
ij
+ G
j
d
) - e
i
d
y
ij
d
] /
jJ
1/(g
ij
+ G
j
d
)
for each jJ
e
ij
d
= V
i
d
/ (g
ij
+ G
j
d
) - (c
ij
+ C
j
d
) / (g
ij
+ G
j
d
) + e
i
d
y
ij
d

if e
ij
d
< 0 then
e
ij
d
= 0
J = J \ {j} r emove ij f r omt he set of ar cs wi t h posi t i ve f l ow
= 0 t hen r epeat t he pr ocedur e
for each jJ
e
j
d
= e
j
d
+ e
ij
d
pr opagat e t he ar c f l ows t o t he head node f l ows
= 1
if k > 1 then
until
ijA
c
ij
( f
ij
+ (e
ij
d
- f
ij
d
)) (e
ij
d
- f
ij
d
) < 0 do = 0.5 ar mi j o st ep
for each ijA updat e ar c f l ows
f
ij
= f
ij
+ (e
ij
d
- f
ij
d
)
f
ij
d
= f
ij
d
+ (e
ij
d
- f
ij
d
)
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)
To execute the LUCE assignment, certain entries have to be made. After calculation, the
page 1253) .
The Table 108 gives an overview of which input attributes have to be maintained.

5.13.6 Persistent storage of bushes
The VISUM format is used for the persistent storage of the demand segment-specific bushes
with the edges that comply with the shortest path in VISUM.
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, regular turns are open in VISUM, whereas U-turns are blocked.
Thus open the U-turns, too, as long as the blocking does not need to be retained for some
other reason. Bear in mind, that this will not have any negative effect on the created routes,
since U-turns are never traversed by loaded routes as long as none of the turns has been
modeled explicitly.
324 PTV AG
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
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.
Based on an "all or nothing" assignment, drivers make use of information gained during their
previous trip for the new 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.
325 PTV AG
Chapter 5.14: Equilibrium_Lohse
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.
Table 111 shows the parameter settings of the Equilibrium_Lohse and the impedance for links
and routes in the unloaded network. Table 112, Table 113 and Table 114 then show three
iterations of the calculation process.
LinkNo Type Length [m] v
0
[km/h] Capacity [car units] R
0
* [min]
1 20 5000 100 1200 03:00
2 20 5000 100 1200 03:00
3 20 5000 100 1200 03:00
5 20 5000 100 1200 03:00
6 20 5000 100 1200 03:00
7 20 5000 100 1200 03:00
8 30 16000 80 800 12:00
9 30 5000 80 800 03:45
10 40 10000 60 500 10:00
11 40 5000 60 500 05:00
Table 111: Impedance in unloaded network, input parameters of Equilibrium_Lohse method
Route Links Length [m] R
0
* [min]
1 1+8+9 26000 0:18:45
2 1+2+3+5+6+7 30000 0:18:00
3 10+11+5+6+7 30000 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
f TT ( )
2.5
1 e
4 0.002 TT
+
-------------------------------------- =
326 PTV AG
LinkN
o
Volume1 [car units] R
1
[min] TT1 f(TT1) Delta 1 R
1
* [min]
1 2000 11:20 2.78 0.0452 0.4796 07:00
2 2000 11:20 2.78 0.0452 0.4796 07:00
3 2000 11:20 2.78 0.0452 0.4796 07:00
5 2000 11:20 2.78 0.0452 0.4796 07:00
6 2000 11:20 2.78 0.0452 0.4796 07:00
7 2000 11:20 2.78 0.0452 0.4796 07:00
8 0 12:00 0.00 0.0450 0.5000 12:00
9 0 03:45 0.00 0.0450 0.5000 03:45
10 0 10:00 0.00 0.0450 0.5000 10:00
11 0 05:00 0.00 0.0450 0.5000 05:00
Route Volume1 R
1
R
1
*
1 0 0:27:05 0:22:45
2 2000 1:08:00 0:41:59
3 0 0:49:00 0:35:59
Table 112: Example of Equilibrium_Lohse: 1. Iteration Step
LinkN
o
2
2
* [min]
1 2000 11:20 0.62 0.0450 0.4925 09:08
2 1000 05:05 0.27 0.0450 0.4962 06:03
3 1000 05:05 0.27 0.0450 0.4962 06:03
5 1000 05:05 0.27 0.0450 0.4962 06:03
6 1000 05:05 0.27 0.0450 0.4962 06:03
7 1000 05:05 0.27 0.0450 0.4962 06:03
8 1000 30:45 1.56 0.0451 0.4855 21:06
9 1000 09:37 1.56 0.0451 0.4855 06:36
10 0 10:00 0.00 0.0450 0.5000 10:00
11 0 05:00 0.00 0.0450 0.5000 05:00
Route Volume2 R
2
R
2
*
1 1000 0:51:42 0:36:50
2 1000 0:36:45 0:39:22
3 0 0:30:15 0:33:08
327 PTV AG
Table 111, Table 112, Table 113 and Table 114 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 of the unloaded network.For impedance R
0
* this is route 2, which
is loaded with 2,000 car trips.
Current impedance R
1
The current impedance R
1
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:
R
1
(link 1) = 3min (1+(2,000/1,200)) = 11min 20s
Estimated impedance R
1
*
The estimated impedance R
1
* of every link consists of the current impedance R
1
and the
estimated impedance R
0
* of the last iteration step. It results from the learning factor . To
determine R
1
* for link 1, the following calculations are necessary:
R
0
* = 3min = 180s
R
1
= 11min 20s = 680s
TT
1
= |R
1
- R
0
*| /R
0
* = |680s - 180s| / 180s = 2.78
LinkN
o
3
3
* [min]
1 1333 06:42 0.27 0.0450 0.4963 07:56
2 667 03:56 0.35 0.0450 0.4953 05:00
3 667 03:56 0.35 0.0450 0.4953 05:00
5 1333 06:42 0.11 0.0450 0.4984 06:22
6 1333 06:42 0.11 0.0450 0.4984 06:22
7 1333 06:42 0.11 0.0450 0.4984 06:22
8 667 20:20 0.04 0.0450 0.4994 20:43
9 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
Route Volume3 R
3
R
3
*
1 667 0:33:23 0:35:07
2 667 0:34:40 0:37:03
3 667 1:01:47 0:47:02
328 PTV AG
R
1
* = R
0
* +
1
(R
1
- R
0
*) = 180s + 0.4796 (680s - 180s) = 420s
Volume 2
The lowest impedance route for R
1
* is route 1. Now two routes exist, route 1 and 2. Every
route is loaded with 1/n, that is, with demand, so that every route is used by 1,000 cars.
Current impedance R
2
2
of every link increases on newly loaded links 8 and 9, and it
decreases on links 2, 3, 5, 6 and 7.
2
*
2
2
and the
1
* of the last iteration step.
Volume 3
The lowest impedance route for R
2
* is route 3 1/3 of the 2,000 car trips are now distributed
over routes 1, 2 and 3.
Current impedance R
3
3
again results from the current volume 3 via the VD function.
3
*
3
3
and the
2
* of the last iteration step.
The concluding route search based on R
3
* determines route 1 as the shortest route. Thus, the
following route volumes result:
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
5.14.2 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
page 1253) . The Table 115 gives an overview of which input attributes have to be maintained.
( ) 0452 , 0
78 , 2 002 , 0 4
e 1 5 , 2
TT 3 V 2 V
e 1 1 V
1
TT f
1
=

+ =

+ =
( )
( )
( )
4796 . 0
0452 . 0
78 . 2 1
15 , 0 5 , 0
15 . 0
1
1
1
1
=
+

+ =
+

+ =
TT f
TT
Bottom Top
Bottom
329 PTV AG
Table 115: Input attributes of the Equilibrium_Lohse procedure
330 PTV AG
Table 116: Output attributes of the Equilibrium_Lohse procedure
5.14.3 Procedure of the Equilibrium_Lohse assignment
The succeeding steps in the Equilibrium_Lohse procedure are illustrated by illustration 98.
331 PTV AG
Illustration 98: Procedure of the Equilibrium_Lohse assignment
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
Upper and lower threshold of delta: upper and lower
parameters of the f(TT) function: V
1
, V
2
, V
3
Terminat ion conditions: max. number iterations N;
E
1
, E
2
, E
3
f or determining t he max. deviation E of impedance
Input
n = 0, R
n=0
* = Impedance in unloaded network
Determine volumes for all routes of any relation ij:
Rout e volume q
r
= (F
ij
/ n) Count
r
n = N or f or every link applies:
R
n
= impedance at current volume n
Route
volumes
Route
search
Query
Impedance
det ermination
yes
no
Determination of shortest route r
n
for all OD pairs based on
impedance R
n-1
*
I f route r
n
is new route
r
: Count
r
= 1
I f route r
n
already exists as route
r
: Count
r
= Count
r
+1
n = n + 1
End
*
1
*
1
=
n n n n
R R R TT
) 1 ( ) (
3 2
1
n
TT V V
n
e V TT f

+ =
( )
) (
n
1
n TT f
n
TT
lower upper
lower
+

+ =
( )
*
n n n
*
n
*
n
R R R R
1 1
+ =
3 2
/
1 1
*
1
E E
n n n
R E E R R

= <
332 PTV AG
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 extend 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 volume-
delay 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:
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.
Illustration 99: ICA-based impedance calculation
Assignment with volume/delay functions by turn
Impedance calculation using ICA
Smoothed
turn
volumes
Adjustment of
the parameters
for turn VDFs
333 PTV AG
Chapter 5.15: Assignment with ICA
VISUM by-passes the separability problem by an approximation approach. The procedure
comprises an interaction of an equilibrium assignment procedure (using conventional VDFs)
and the node impedance calculation (ICA). First, some assignment iterations determine turn
volumes among others which are used as input data for ICA. With ICA, turn capacities and wait
times are determined first for the given volumes resulting from assignment. Then the volume
of each individual turn is varied while the volumes of the other turns via the same node are
retained for the wait time estimation with various load cases. From the determined wait times
a volume-delay function is interpolated for each turn subsequently. These turn-specific VDFs
will then be used in the next iteration of the 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 volume-delay functions are stabilized for some iterations in each case to favor
convergence. The feedback loop between assignment and ICA terminates as soon as the
impedances calculated by the volume-delay function or ICA respectively do not differ
significantly anymore. For links and connectors, if applicable, the assignment with ICA uses
regular volume-delay functions. Their parameters do not depend on the individual network
object, however, for links they depend on the link type only.
5.15.2 Evaluation of the procedure
Specific advantage: Usually, ICA cannot be applied properly while an assignment is running
since the volume-delay functions are not separable. By "freezing" the conflicting flows for some
iterations of the equilibrium assignment, the Turn VDFs become "approximately separable".
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 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.
Also the assignment itself requires more computation time than a usual equilibrium
assignment, since additional ICA calculations are required and because the adjustment of the
turn VDFs after some balancing iterations at a time usually leads to a regression in
convergence which has to be caught up accordingly thereafter. That is why you might
calculate an assignment with ICA for the base scenario of a project, where as a by-product the
volume-delay functions by turn are adjusted to the volumes reached in the balanced state. You
can continue to use these VDFs without modifications as far as the volumes do not significantly
change in the scenarios which are to be analyzed subsequently. For this, VISUM makes it
possible to calculate a normal equilibrium assignment (without ICA, i.e. fast), however using
the turn-specific VDFs in this process which result from the recent assignment with ICA.
334 PTV AG
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 the calculation, the results are available in the
output attributes and can be displayed in the list view (see User Manual, Chpt. 12.1,
page 1227) or in the network editor (see User Manual, Chpt. 12.2, page 1253) . Table 117
gives an overview of which input attributes have to be maintained. It is of particular
importance, that for those nodes whose turn impedances shall be calculated in detail with ICA,
the option Node impedance calculation (ICA) is selected for the attribute Method for
impedance at node and that the attribute Use preset method for impedance at node is set
to TRUE. Table 119 lists the output attributes which store the results of the procedure.
The following prerequisites are required for the assignment with ICA:
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. Whether the
calculation can be performed correctly for all these nodes you can verify quickly via menu
Calculate >Network check by means of the option Viability for ICA.
For turns, the design volume PrT needs to be a volume-representing attribute (Volume PrT
or Volume PrT with base). The configuration has to be set via menu Calculate >
Procedures > tab Functions > navigator entry PrT functions > 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. For consistency reasons, the factor
needs to be set to 1.0, too, for any other turn (turns not to be calculated by ICA).
335 PTV AG
Table 117: Input attributes of the assignment with ICA
(x) Can be used optionally
336 PTV AG
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.
Additionally to the common volume and travel time attributes, for turns and main turns the
following output attributes are provided which are only filled by the assignment with ICA:
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
indications, for example, which of the turns show significant differences between the
impedance calculations with ICA and the volume-delay function.
As long as the procedure is running, you can watch the process in the "Goodness of PrT
assignment with ICA" list.
Files of the *.csv data type are created which store the intermediate turn attribute data.
These files are helpful for comparisons of the development of the attribute values of
individual turns in different iterations.
Output attributes of the recent iteration are stored as user-defined attributes, if applicable.
This data can be used for the comparison of the convergence reached in different runs of
the assignment with ICA. However, the created user-defined attributes need to be copied
prior to the second run.
Note: Please note, that Toll PrTSys (marked by x1) has to be inserted manually in the
impedance function to have an effect.
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
Capacity that was recently used with ICA assignment. In contrast, the
attribute Capacity PrT specifies the initial capacity of the turn at the start
of the procedure which can be reduced by the ICA calculation.
Final t0 for assignment with
ICA
t0 that was recently used with ICA assignment. In contrast, the attribute
t0-PrT specifies the loss time of the turn in the unloaded network at the
start of the procedure. This value is changed by the ICA calculation.
Final smoothed volume for
assignment with ICA
Smoothed volume resulting from recent iteration.
tCur-PrTSys for assignment
with ICA
tCur-PrTSys from the turn-specific VDF with final VD function
parameters. In contrast, the attribute tCur-PrTSys stores the result
calculated in the recent ICA calculation.
Impedance-PrTSys for
assignment with ICA
Impedance-PrTSys from the turn-specific VDF with final VD function
parameters. In contrast, the attribute Impedance-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
Table 118: Additional attributes of turns and main turns for assignment with ICA
337 PTV AG
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
returned in the same way as for nodes of the Two-way stop type.
Table 119: Output attributes of the assignment with ICA
The precise times, when attribute data is stored in an iteration is described with the procedure
(see "Description of the procedure" on page 337).
Additionally please note the following:
Also for other network objects, the volumes, times, and impedances are evaluated and
modified.
The assignment with ICA ignores the global attribute for the Design volume PrT. Neither
the global factor is taken into account. The smoothed volumes of the turns are used
instead.
5.15.4 Description of the procedure
The assignment with ICA is based on the iterative solution for the user optimum with volume-
delay functions for all network objects. The distinctive feature is that the parameters of the turn
VDFs can be set by turn 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 332).
338 PTV AG
It is possible to activate the blocking back model as long as the procedure is running. In this
case, the blocking back model is applied after the completion of the embedded assignment
procedure to adjust the turn volumes first and the link impedances then. However, the link
capacity remains unchanged. The modified turn volumes are regarded by ICA.
First the embedded assignment procedure is performed. For those nodes, for which ICA
calculation has been activated, the VDFs by turn are used. This means, that no ICA is
applied as long as the embedded assignment procedure is running.
A specific description is provided for the definition of the volume delay functions applied by
turn (illustration 100, query 2: Is the turn share T below p
2
?).
Once the embedded assignment procedure is finished the blocking back model can
optionally be applied. Please note, that the blocking back model is not used as long as the
embedded assignment procedure is executed.
The global parameters for the blocking back model are ignored, if the blocking back model
is used (see User Manual, Chpt. 5.5.2, page 884). Only the parameters set for the
procedure assignment with ICA will take effect.
Only the capacities of turns are adjusted, when the blocking back model is used. Capacities
of links or nodes are not modified. However, link impedances are adjusted. Only Phase 1
of the blocking back model is performed.
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.
Subsequently to the assignment and to the optionally performed blocking back model, the
impedances and the capacities of the turns are calculated via ICA. For the ICA calculation,
the smoothed turn volume (also with base volume, if applicable) is used as design volume
PrT.
The calculation of new turn-specific VDFs is performed in two steps, in each case for all
turns or main turns separately. In the first instance, the parameters of the volume-delay
function are determined by interpolation of three sampling points. One sampling point is
known from the smoothed turn volumes resulting from the assignment and the related
impedance, for two more sampling points, the volume of the currently processed turn is
reduced or increased, while the volumes of other turns via the node are kept; then the
impedance of the current turn is calculated again via ICA. Since the VDF which is to be
interpolated shows three free parameters (t
0
, 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, that the VDFs of the recently performed embedded
assignment are suitable. You can reproduce the equilibrium state from the recent
embedded assignment as follows: For the ICA nodes, select the turn-specific VDFs (option
"From previous assignment with ICA") for the method for impedances at node parameter
339 PTV AG
after the procedure is finished. In the flow diagram, q
Tn
represents the volume of turn T in
iteration n.
340 PTV AG
Illustration 100: Procedure of the assignment with ICA
341 PTV AG
5.15.5 Used turn VDF
Illustration 101: Turn volume delay function of the assignment with ICA
where
For each (main) turn, the factors a and b are updated with every ICA impedance calculation
during the assignment. The values that apply to the recent iteration can be found in the (main)
turn attributes Final A for assignment with ICA and Final B for assignment with ICA.
a and b Attributes of the particular (main) turn
sat
crit
sat
crit
= 1.1
b b = 3b (thus more steeply compared to sat

sat
crit
)
a
a =
t
0
t
0
=
a and t
0
These values have been selected, so that both branches are differentiatedly linked together
for sat = sat
crit
.
0,0000000000
5,0000000000
10,0000000000
15,0000000000
20,0000000000
25,0000000000
30,0000000000
35,0000000000
40,0000000000
s
Vol ume/Capacity Rat io
ICA Turn Volume/Del ay Function
ICA Turn
Part 1
Part 2
t
cur
sat ( )
t
0
a sat
b
+ sat s at
crit
t
0
' a' s at
b'
+ sat s > at
crit
=
a
3
--- sat
crit
b b'
t
0
a sat
crit
b
a' sat
crit
b'
+
342 PTV AG
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 289) 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.
5.16.2 Input and output attributes of the stochastic assignment
To execute the stochastic assignment, certain entries have to be made. Table 120 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 1227) or in the network editor (see User Manual, Chpt. 12.2, page 1253) .
343 PTV AG
Chapter 5.16: Stochastic assignment
Table 120: Input attributes for the stochastic assignment
The abbreviations represent the following:
344 PTV AG
Table 121: 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 102).
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.
(x) Can be used optionally
345 PTV AG
n = 0
Start of
external
iterartion
Calculate impedance R in the unloaded net work for all
network elements.
Calculate 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 rout e only, if the detour test is successful,
i.e. the new route is not a t rivial version of an existing
route.
Calculate independence f actor (commonalit y factor) that
t akes into account the relative similarity of the rout es or
calculate t he independence (Ben Akiva)
Number of new shortest routes > 0
Delete all routes with R > a R*
min
+ b and
t
0
> c t
0,min
+ d
Count er for
external
iterat ion
Route search
Route
preselection
Independence
no
Search
impedance
n = n + 1
Termination
external
iterat ion
ja
stop
346 PTV AG
Illustration 102: 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 r
2
if a
route r
1
already exists that matches r
2
, with the exception of a subsection, and if this
m = 0
Start of internal
iteration
Set impedance R or R* of all network objects to
impedance in the unloaded network.
Calculate R * of all routes as a total R * for all traversed
network objects.
Correct impedance using impedance factor.
Calculate R * for all network objects f rom the volumes that
result fromthe route choice.
The search impedance is an estimated R * value that is
calculated as in the Equilibrium_Lohse procedure:
m = max. number of internal iterations or
is valid for the impedance of all network elements, and
is valid for the volume of all routes
Counter for
internal
iteration
Choice
impedance
Route volume
Update search
impedance
no
Initialisation of
choice
impedance
m = m + 1
Termination
criterion for
internal
iteration
ja
Assignment of demand across the routes in accordance
with Logit, Box-Cox, Kirchhof f, Lohse or Lohse with
variable beta results in route volumes q
rm
*
Route choice
n = max. number of external iteration
Termination of
external
iteration
yes
no
stop
m
q m q
q
rm m r
rm
' ) 1 (
) 1 (
+
=

( )
*
old new
*
ld
*
new
R R R R
o
+ =
) , ) , max( min(
3 2
*
1
*
1
*
1
*
E E R R E R R
m m m m
+

) , ) , max( min(
6 5 ) 1 ( 4 ) 1 (
E E q q E q q
m r rm m r rm
+

347 PTV AG
subsection in r
2
is significantly longer than in r
1
. More precisely, r
2
is discarded in favor of r
1
if
the following applies (illustration 103).
r
1
= AT
1
B
r
2
= AT
2
B
Length(T
2
) > Factor Length(T
1
)
Illustration 103: 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 104):
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.
348 PTV AG
Illustration 104: 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:
Case 1 Portion
expected Logit
Route 1 50% 50%
Route 2 50% 50%
Case 2 Portion
expected Logit
Route 1 33% 33%
Route 2 33% 33%
Route 3 33% 33%
Case 3 Portion
expected Logit
Route 1 approx.
28%
33%
Route 2 approx.
44%
33%
Route 3 approx.
28%
33%

Route 1
Route 2
Impedance R1 = R2

Route 2
Impedance R1 = R2 = R3
Route 1
Route 3

Route 2
Impedance R1 = R2 = R3
Route 1
Route 3
349 PTV AG
or
with
Thus, C
rs
equals 1, if the two routes are identical, and will be 0, if the two routes do not overlap.
The commonality factor C
rs
is determined for all route combinations. Then, the correction factor
CF
r
of a route r compared to any other route s is defined as follows:
The correction factor of a route r is 1 if the commonality factors C
rs
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 CF
r
is then regarded in the Logit model as follows:
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 CF
r
can be determined using a simpler approach according
to Ben Akiva. It is then defined as:
or
with
C
rs
Similarity of the routes r and s (Commonality factor)
t
0rs
Time t
0
of the common sections of the routes r and s
t
0r
Time t
0
of route r
l
rs
Length l of the common sections of the routes r and s
l
r
Length l of route r
t
0a
Time t
0
of link a
t
0r
Time t
0
of route r
l
a
Length l of link a
l
r
Length l of route r
N
ija
Number of routes of the OD pair ij that lead across link a
C
rs
t
0rs
t
0r
t
0s
--------------------- = C
rs
l
rs
l
r
l
s
---------------- =
CF
r
1
C
rs
s
-----------------
1
1 C
rs
r s
+
--------------------------------- = =
P
e
V
r
CF
r
e
V
s
CF
s
( )
s 1 =
N
-------------------------------------------- =
CF
r
t
0a
t
0r
------
1
N
ija
---------

a P
r
=
CF
r
l
a
l
r
----
1
N
ija
---------

a P
r
=
350 PTV AG
5.16.5 Example for the stochastic assignment
The Table 122 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 R
0.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.
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 t
0
or to the length. The Table 123 shows the commonality factors C. From
this, the correction factor CF
r
of route r is calculated.
Route 1
LinkNo Type v
0
[km/h] Length [m] Capacity [car units] R
0
* [min] R
0
* [s]
1 20 100 5000 1200 03:00 180
2 20 100 5000 1200 03:00 180
3 20 100 5000 1200 03:00 180
5 20 100 5000 1200 03:00 180
6 20 100 5000 1200 03:00 180
7 20 100 5000 1200 03:00 180
8 30 80 16000 800 12:00 720
9 30 80 5000 800 03:45 225
10 40 60 10000 500 10:00 600
11 40 60 5000 500 05:00 300
Route Links Length [m] R
0
* [min] R
0
* [s]
1 1+8+9 26000 0:18:45 1125
2 1+2+3+5+6+7 30000 0:18:00 1080
3 10+11+5+6+7 30000 0:24:00 1440
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 122: Impedance in the unloaded network, input parameters for stochastic assignment
CF
1
1
C
1j
j
-----------------
1
1.0 0.16 + 0.0 +
-------------------------------------- 0.8596 = = =
351 PTV AG
Route 2
Route 3
The share by route is calculated from the correction factor according to Cascetta and from the
impedance R
min
0
in the unloaded network.
For Route 1, the portion is calculated using the Logit model as follows:
In the same way, the portions showed in the Table 124 result for Routes 2 and 3. The volume
of each route q
r1
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 105).
This results in the impedances R
1
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 pair t
0ij
t
0i
t
0j
C
ij
1.1 1125 1125 1125 1.00
1.2 180 1125 1080 0.16
1.3 0 1125 1440 0.00
2.1 180 1080 1125 0.16
2.2 1080 1080 1080 1.00
2.3 540 1080 1440 0.43
3.1 0 1440 1125 0.00
3.2 540 1440 1080 0.43
3.3 1440 1440 1440 1.00
Table 123: Calculation of the commonality factor C for all route pairs
Route E
R
min
0
exp(R
min
0
)E
Portion P q
r1
R
1
1 0.8596 1125 0.279079049 0.425 849.4 2470
2 0.6264 1080 0.212737561 0.324 647.5 1961
3 0.6978 1440 0.165335421 0.252 503.2 2848
Sum 0.657152032 1.000 2000.0
Table 124: Volumes in the first internal iteration step m = 1
CF
2
1
C
2j
j
-----------------
1
0.16 1.0 + 0.43 +
----------------------------------------- 0.6264 = = =
CF
3
1
C
3j
j
-----------------
1
0.0 0.43 + 1.0 +
-------------------------------------- 0.6978 = = =
P
1
0.8596 e
-0.0011125
0.8596 e
-0.0011125
0.6264 e
-0.0011080
0.6978 e
-0.0011440
+ +
---------------------------------------------------------------------------------------------------------------------------------------------------- 0.425 = =
352 PTV AG
Illustration 105: 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 R
min
1
is calculated.
Since = 0.5, this impedance results from the formation of the mean value of R
min
0
and R
1
. On
the basis of R
min
1
, as in the first iteration step, the assignment is then made for the 3 routes.
For each route, the interim result is q
r2
. To smooth the volumes between two iteration steps,
the MSA method (Method of Successive Averages) is used.
For m = 2, this results in the following for the volume of Route 1:
This route volume then leads to the link volumes and impedances of the second iteration step
(Table 125). The iterations are repeated until the termination criteria are met.
Route E
R
min
1 exp(R)E Portion P q
r2
q
r2
R
2
1 0.8596 1797.6 0.142432 0.3944 788.8 819.1 2405.2
2 0.6264 1520.7 0.136919 0.3791 758.3 702.9 2016.0
3 0.6978 2144.0 0.081775 0.2264 452.9 478.0 2785.6
Sum 0.361126 2000
Table 125: Volumes in the second internal iteration step m = 2
A Village
X City
q
rm
q
r m 1 ( )
m 1 ( ) q
rm
' +
m
---------------------------------------------------------- =
q
r2
849.4 2 1 ( ) 788.8 +
2
------------------------------------------------------ =
353 PTV AG
Chapter 5.17: TRIBUT
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-Equlibrium (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 126 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 1227) or in the network editor (see User Manual, Chpt. 12.2, page 1253) .
354 PTV AG
Table 126: Input attributes for TRIBUT
The abbreviations have the following meaning:
x1 Only for link toll
x2 Only for area toll or matrix toll
355 PTV AG
Table 127: 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 R
r
of a route r consists of travel time t
r
and monetary costs c
r
:
Here, VT is the value of time in [/h], for example. Though this equation applies to all toll-
regarding 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.
t
L
= t(Vol
L
) Travel time on a link L as a function of the volume
Vol
L
Volume of link L
C
L
Toll value for using link L
VT Value of time in [/h], for example
R
r
t
r
c
r
VT + =
356 PTV AG
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.

Area toll
Especially toll systems for inner city areas often use a different type. For area toll, a physically
cohesive section of the network is allocated as toll area - and a distance-independent fixed
charge is collected if a route partially lies in the toll area:
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.
R
r
t
r
c
r
VT
------- + t
L
L r
c
VT
------- if a L R lies in the toll area
0 otherwise
+ = =
357 PTV AG
Illustration 106: Example for area toll : The London Congestion Charging Zone
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 below, all
connector nodes of each 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:
c
L
= 0 for all links L
c
C
= 0 for all connectors C
for all turns T, with
T
= 1, if turn T leads from a link inside the toll area to a link
outside or vice versa, i.e. if the toll area border is crossed. Otherwise,
X
= 0.
for all transitions X from connectors to links, where
X
= 1, if the transition X leads
to a link in the toll area or originates from there. Otherwise,
T
= 0.
illustration 107 illustrates the principle:
c
T

T
c
2
--- =
c
X

X
c
2
--- =
358 PTV AG
Illustration 107: 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. The area toll
type does not regard the link attribute Toll-PrTSys.
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
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.

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 108).
Note: Only the TRIBUT-Learning procedure takes the area toll into consideration.
Link outside
of toll area
Link inside
of toll area
Turn with toll
Connector
with toll
Connector
without toll
Zone 1 Zone 2
359 PTV AG
Illustration 108: 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 toll amounts for
longer routes can be defined irrespectively of the toll amounts for shorter sections of a longer
route. Usually, those tariffs are on a diminishing scale, thus the rate per kilometer declines with
increasing total distance.
As a matter of principle, such a matrix toll (which is named according to the fare matrix) cannot
be reduced to summing up the toll amounts by link. Let us have a look at the example in
illustration 109:
Illustration 109: Example of a matrix toll
The links 1-2 and 2-3 form a highway corridor with matrix toll. For that, define the toll area first
by creating a network object 'toll system' of the matrix 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 a matrix for each transport system which contains the toll
amounts between all border nodes of the toll area. In this example, these are the nodes 1, 2,
and 3. The toll amounts are listed in Table 128:
from / to node 1 2 3
1 0 2 3
2 2 0 2
3 3 2 0
Table 128: Toll amounts for the example network
Link outside
of toll area
Link inside
of toll area
1 2 3
Node
with number
1
360 PTV AG
Please note, that the toll amount for the overall link is less compared to the two individual links.
For each pair (entry, exit) in the toll area, TRIBUT generates a virtual link with the toll amount
from the matrix in the network and uses these virtual links for the shortest path search. In
contrast, the original links in the toll area are not regarded for the shortest path search. For
travel time computation, the volumes by virtual link are transferred back to the original links.
This allocation is always based on the route with the minimum time (regarding t0) required
between 'from node' and 'to node' of the virtual link. illustration 110 shows the graph that is
generated for the shortest path search in the example.
Illustration 110: Shortest path search graph with matrix toll
This modeling approach assumes a degressive toll matrix, i.e. if there are three nodes A, B,
and C, always c
A-C
c
A-B
+ c
B-C
applies. Furthermore, the number of virtual links that are added
to the search graph exhibits quadratic growth proportionally to the toll area's number of border
nodes.Thus you should use a toll matrix only in those cases where the toll area is connected
to the surrounding network by a manageable number of nodes.
In a VISUM model, you can define several toll systems of the matrix toll type.Nevertheless,
each link may belong to just one toll system. Then, virtual links are generated for each toll
system and the toll amounts from the valid toll matrix are attributed to them.
With matrix toll, the link attribute Toll-PrTSys is not regarded.
The Value of Time as stochastic parameter
Additionally, the TRIBUT procedure features the definition of the value of time (VT) and the
impact of this definition (Table 129). This description is reduced to the link toll case, since the
basic principle does not differ by toll type.
The complexity of a bicriterial route choice procedure can be made clear in a time-cost diagram
(illustration 111).
Note: Only the TRIBUT-Learning procedure takes the matrix toll into consideration.
"Conventional" toll assignment TRIBUT
VT is constant for all vehicles. VT is concurrent distributed, which means that each
vehicle of the matrix specifies an individual VT for
route choice.
monocriterial
In the full course of the assignment, only one
criterion is used, because the costs c
R
of a route
are converted into a constant time penalty.
bicriterial
During the assignment, both criteria (t
R
and c
R
)
must always be available for each path.
Table 129: Comparison of conventional toll assignment and TRIBUT
Link outside
of toll area
Virtual link
with road toll
Node
with number
1
1
2 3 2 2
3
2
361 PTV AG
Illustration 111: Time-cost diagram
Each point on the diagram, for example A = (t
A
,c
A
), corresponds with a route of the same
origin destination relation.
A certain time value VT corresponds with a family of parallel straight lines with a negative
slope.
If two routes lie on one VT straight, they are equally good (for a user with the same VT).
This VT is also characterized as a critical VT for two routes.
5.17.3 LogN distribution of the random variable VT
The TRIBUT procedure is based on the assumption, that each vehicle has its individual VT.
This is displayed by a random variable and the corresponding probability distribution. TRIBUT
uses a LogNormal distribution for the random variable VT.
The two distribution parameters apply:
has the following properties:
The probability is equal to zero for negative values.
Route B
cost
c
time t
c
A
t
A
Route A
c
B
t
B
VT = - |c
B-
c
A
|/ |t
B
-t
A
|
Position parameter, corresponds with the Median of
Distribution parameter
This parameter corresponds with the standard deviation of the associated standard normal variable.
( ) , vt
N
log VT =
vt ( ) , vt
N
log VT =
( ) , vt
N
log VT =
362 PTV AG
The position parameter corresponds with the Median of , which
means that the distribution function adopts the value of 50 % for VT= .
The illustrations show the density function (illustration 112) and the distribution function
(illustration 113).
Logarithmic normal distributions
Illustration 112: Density function
Illustration 113: Distribution function
vt
( ) , vt
N
log VT =
vt
0,000
0,010
0,020
0,030
0,040
0,050
0,060
0 10 20 30 40 50 60 70 80 90
val ue of ti me
g
(
v
o
t
)
Density function g1(vot)
Density function g2(vot)
0,000
0,200
0,400
0,600
0,800
1,000
1,200
0 10 20 30 40 50 60 70 80 90
val ue of ti me
G
(
v
o
t
)
Distribution function G1(vot)
Distribution function G2(vot)
363 PTV AG
5.17.4 Route search - efficient frontier as exclusive criterion
Whereas a unique best path (shortest path) can always be determined for all monocriterial
(conventional) methods, for TRIBUT, many (several) best paths have to be specified in the
route search as well as kept in RAM, because the VT which is not unique. Hence, the resulting
complexity of the route search can, however, be limited with critical values of time (as shown
in illustration 114).
Illustration 114: Path Search
illustration 114 shows a route search with six routes. It can be verified graphically or
analytically, that there is no VT for which route X or Y would be preferred over A, B, C or D.
Generally spoken, the VT-straight lines A-B, B-C, C-D form a convex front. All routes which lie
to the right of this convex front no longer have to be observed, because they cannot be
optimal for any user (for no VT).
The relevant routes on the convex front are also designated as set of the efficient routes. Only
these efficient routes are saved for further search and later distribution.
There are two aspects:
For bicriterial procedures you can also discard most alternatives from a multitude of
possible routes, so that the route search can be calculated with the finite time spent and
memory used.
The bicriterial procedure has to memorize and save several paths at the same time,
whereas during and after a monocriterial search always one solution (best path) is found for
each source destination relation.
5.17.5 Route split
The result of a route search only comprises the efficient routes. Under these, the demand for
an OD relation is set. The critical VT are decisive for every neighboring routes on the efficient
front. In the example, there are three critical values of time - A/B, B/C and C/D.
B
c
t
D
C
A
Y
X
VT
crit
C/D
VT
crit
B/C
VT
crit
A/B
364 PTV AG
As illustrated in illustration 115 the demand shares of the four efficient routes can be derived
from the probability distribution of the VT.
Illustration 115: Distribution of the traffic demand onto the routes
5.17.6 Route balancing in the equilibrium iteration
Similar to the equilibrium assignment (see "Equilibrium assignment" on page 301), each new
TRIBUT iteration starts with a route search. If new routes are found which fall on the convex
front, they are included in the set of relevant routes. The equilibrium formation is then executed
by a coupled demand equalization between the routes (illustration 116). The following steps
are carried out:
Balance between the route of a toll level
Balance between the neighboring toll levels
Constant correction of the course of the convex front and adjustment of the critical values
of time.
0%
50%
100%
P (A)
VTcrit A/B VTcrit B/C VTcrit C/D
P (D)
P (C)
P (B)
Matrix distribution to the found Tribut best routes
according to the respective distribution function
Initial solution
Shift of demand between the efficient routes of each OD
Determination of efficient routes for curr. time impedances
End
Found new routes?
Route search
yes
no
Route spl it
365 PTV AG
Illustration 116: Equilibrium formation with TRIBUT
5.17.7 Route distribution in the iteration of the TRIBUT Equilibrium_Lohse
The TRIBUT Equilibrium_Lohse is a modified version of the conventional French procedure,
where procedural steps of the Equilibrium_Lohse method are used.
Route search is also executed at the beginning of the iteration of the Equilibrium_Lohse (see
"Assignment with ICA" on page 332). For all resulting efficient paths, the percentage is
determined via the critical values of time. All efficient paths are added to the list of best paths
from the preceding iterations including their current percentage. For existing paths all
percentages are added.
5.17.8 List outputs
Via the menu Lists > Toll, the list types Toll matrices and Toll systems are provided, which
offer the following attributes for selection:
c
t
C
B
N
A
366 PTV AG
Illustration 117: Attribute selection for the Toll systems list
Illustration 118: Attribute selection for the Toll matrices list
367 PTV AG
Chapter 5.18: Dynamic User Equilibrium (DUE)
5.18 Dynamic User Equilibrium (DUE)
The quantitative analysis of road network traffic performed through static assignment models
yields the transport demand-supply equilibrium under the assumption of within-day stationarity.
This implies that the relevant variables of the system (i.e. user flows, travel times, costs) are
assumed to be constant over time within the reference period. Although static assignment
models satisfactorily reproduce congestion effects on traffic flow and cost patterns, they do not
allow to represent the variation over time of the demand flows (for example, around the rush
hour) and of the network performances (for example in presence of time varying tolls, lane
usage, signal plans, link usage permission); Most importantly, they cannot reproduce some
important dynamic phenomena, such as the formation and dispersion of vehicle queues due to
the temporary over-saturation of link sections, and the spillback, that is queues propagation
towards upstream links. For these use cases, dynamic models are available.
5.18.1 Fields of application of the Dynamic User Equilibrium procedure
The Within-Day Dynamic Traffic Assignment (WDDTA) models are conceived to overcome the
limits of static models. Among them, the Dynamic User Equilibrium (DUE) model embedded in
VISUM presents several new and unique features, yielding an algorithm highly efficient both in
terms of memory usage and computing time. Thus, this model can be applied to large networks
(hundreds of zones and up to one hundred thousand links and nodes) with long periods of
analysis (possibly the entire day). It is particularly suitable for the following application fields.
Simulation of heavily congested urban and extra urban networks, where oversaturation
conditions and the back propagations of congestion among adjacent roads are present
over a large part of the network for several hours each day.
Simulation of networks with transient congestion effects, leading to route choice varying
during the assignment period.
Simulation of networks in presence of dynamic management and/or time varying access
policies, such as time varying tolls, signal timing plans, lane usage permission.
Simulation of incident effects and incident management
Simulation of evacuation plans, in particular when the maximum evacuation time is
required.
Below you can find a complete overview of the model underlying the Dynamic User Equilibrium
procedure implemented in VISUM. However, in order to improve readability, any bibliographic
reference is omitted, along with many analytic proofs. For those, and for a deeper insight into
the model and/or the theories underlying it, the reader may refer to the bibliographic section,
which includes all the scientific papers on which this model is based (see "Literature" on
page 715).
5.18.2 Overview of the dynamic equilibrium assignment model
This model is aimed at solving the Within-Day Dynamic Traffic Assignment (WDDTA) on
link networks addressing explicitly the simulation of queue spillovers. It is based on a
macroscopic approach, the Dynamic User Equilibrium (illustration 119).
368 PTV AG
Illustration 119: The dynamic user equilibrium problem
Apart from the temporal dimension, the main difference between the static and the dynamic
user equilibrium relates to the consistency constraints between arc and path model variables.
While in the static case these constraints involve only the spatial dimension of the system, in
the dynamic case they concern the temporal dimension also. More specifically, for given path
flows, the determination of the arc flows, which in the static case requires only the arc-path
incidence matrix, in the dynamic case involves also the travel times on the network; that is, the
network flow propagation model depends also on the path performances (diagonal arrow in
illustration 119).
The present formulation of the WDDTA has three essential innovations compared to existing
WDDTA methods:
1. Instead of a simulation approach, it adopts a temporal profile approach, where the value of
a given variable of the problem is determined as a function of time for the entire period of
analysis, based on the temporal profiles of the other variables of the problem, which are
assumed to be fixed to their current value; this approach, conceptually depicted on the right
hand side of illustration 120, has an iterative nature, since each variable has to be
recalculated until a convergence is achieved.
369 PTV AG
Illustration 120: Time slice approach (left side) and time profile approach (right side) to the Continuous
Dynamic Network Loading problem
2. Spill-back can be modeled explicitly simply by switching between two alternative network
performance models. Without spillback, arc performance (the relationship between arc
inflow and outflow time series) depends only on the properties of that arc; with spillback,
capacities upstream of bottlenecks are reduced so that arc storage capacities are not
exceeded (illustration 121).
Illustration 121: Scheme of the fixed point formulation for the WDDTA with spillback congestion
3. The path choice model can adopt either a deterministic view where only objectively least-
cost paths are loaded, or a Probit view where impedances are perturbed stochastically to
reflect subjective user perceptions.
This approach presents several advantages.
Consistency between path and link flows (network loading) is achieved in the same
iteration as the equilibration between demand and supply. Nested loops are avoided.
An implicit path approach generates rational path probabilities without the need to
enumerate all paths.
A major advantage of the temporal profile approach, is that the assignment period may be
subdivided into long time intervals (typically 5-15 minutes), instead of a few seconds for the
link flows, travel times, at time
0
i
link flows, travel times, ad time
i+1
I
l
i
n
k

f
l
o
w

t
e
m
p
o
r
a
l

p
r
o
f
i
l
e
s
l
i
n
k

t
r
a
v
e
l

t
i
m
e

t
e
m
p
o
r
a
l

p
r
o
f
i
l
e
s
state of the network
p
e
r
i
o
d

o
f

a
n
a
l
y
s
i
s
p
e
r
i
o
d

o
f

a
n
a
l
y
s
i
s
0
i
i+1
I
l
i
n
k

f
l
o
w

t
e
m
p
o
r
a
l

p
r
o
f
i
l
e
s
l
i
n
k

t
r
a
v
e
l

t
i
m
e

t
e
m
p
o
r
a
l

p
r
o
f
i
l
e
s
p
e
r
i
o
d

o
f

a
n
a
l
y
s
i
s
p
e
r
i
o
d

o
f

a
n
a
l
y
s
i
s
network flow propagation
model
implicit path enumeration
route choice model
demand
flows
arc travel times
network loading
map
network performance
model
arc conditional
probabilities
arc costs
arc perf ormance
function
arc flows
370 PTV AG
simulation approaches, saving computation time and memory. This allows overcoming the
difficulty of solving WDDTA instances on large networks and long periods of analysis.
The complexity of the algorithm is roughly equal to that of a static assignment multiplied by
the number of (long) time intervals introduced.
For queue spillover modeling, the interaction among the flows on adjacent arcs is propagated
in terms of time-varying arc exit capacities. The approach is then to reproduce the spillback
phenomenon as a hypercritical flow state, either propagating backwards - from the final section
of an arc - and reaching its initial section, or originating on the latter that reduces the capacities
of the arcs belonging to its backward star and eventually influences their flow states.
The description of the dynamic user equilibrium has the following structure. First, the main
variables underlying the continuous model are introduced, along with some significant results
of the traffic flow theory underlying the presented model (see "Mathematical framework of the
Dynamic User Equilibrium" on page 370). Subsequently, the network performance model and
its submodels are described (see "Network performance model" on page 374). Then, the
display of the network loading map (see "Assignment of the network demand (network
loading)" on page 384) is followed by a description of the overall Dynamic User Equilibrium
model, both for the deterministic and Probit case (see "The overall model" on page 386). A
numeric example including the analysis rounds off the procedure description (see "Example of
the Dynamic user equilibrium" on page 388).
5.18.3 Mathematical framework of the Dynamic User Equilibrium
As the analysis is carried out within a dynamic context, the model variables are temporal
profiles, here represented as piecewise continuous functions of the time variable t.
Users trips on the road network are modeled through a strongly connected oriented graph G =
(N, A), where N is the set of the nodes and A N is the set of the arcs. Each link, turn, and
connector in the VISUM network corresponds to an arc. Each VISUM network node and zone
corresponds with a node from G.
Each arc a is identified by its start node (FromNode) TL(a) and by its end node (ToNode)
HD(a).
Thus a = (TL(a), HD(a)).
Example
For an arc a representing a link in the VISUM network, TL(a) would correspond to its FromNode
and HD(a) to its ToNode. The forward and backward star of node xN are denoted,
respectively, FS(x) ={aA: x = TL(a)} and BS(y) = {aA: y = HD(a)}. The zones constitute a
subset Z N of nodes.
When traveling from a node oN to anode dZ users consider the set K
od
of all the paths
connecting o and d on G. We are interested in the n:1 many-to-one shortest path problem from
each node oN to a given destination dZ. Graph G is assumed to be strongly connected, so
that K
xd
with xN dZ is non-empty.
Path topology is described through the following set notation:
A(k) = concatenated sequence of arcs constituting the path kK
od
from oN to dZ.
The following notations are adopted for the network volumes.
371 PTV AG
The following applies by definition:
(26)
For the calculation of network performance, travel times are introduced through inflow-outflow
functions, and the following notation is adopted.
Due to the presence of time-varying costs, it may be convenient to wait at nodes in order to
enter a given arc later. In the following, it is assumed that vehicles are not allowed to wait at
nodes, but paths with cycles may result. However, the shortest paths include at most a finite
number of cycles.
Since waiting at nodes is not allowed, the path exit time T
k
() is the sum of the travel times of
its arcs A(k), each of them referred to the instant when these vehicles enter the arc when
traveling along the path. Moreover, assuming that path costs are additive with respect to arc
costs, its cost C
k
() is the sum of the costs of its arcs A(k). The outflow time or the cost,
respectively, of path k can then be retrieved through the following recursive equations:
(27)
(28)
where a = (o, x)A is the first arc of k and hK
xd
is the rest of path k (illustration 122).
D
od
()
Vehicle demand, which are moving from origin oN to destination d and are departing at
time t
f
a
() Vehicle flow, which at time t is traversing arc aA
F
a
() cumulated vehicle flow, which at time t is traversing arc aA
u
a
() Exit flow from arc aA at time t
c
a
() Cost of traversing arc aA for vehicles entering it at time
t
a
() Outflow time of arc aA for vehicles entering it at time
f
a
-1
()
Inflow time of arc aA for vehicles exiting it at time
C
k
() Cost of path kK
od
from oN to dZ for vehicles departing from node o at time
T
k
() Outflow time of path kK
od
from oN to dZ for vehicles departing from o at time

=

d ) (
a
) (
a
f
F
( ) ( ) ( )
a
t
h
T
k
T =
( ) ( ) ( ) ( )
a
t
h
C
a
c
k
C + =
372 PTV AG
Illustration 122: Recursive expressions of path exit time, entrance time and cost
The strict First In First Out (FIFO) rule holds if the following property is satisfied for each arc
aA:
, for all t > t (29)
The monotonicity expressed by (29) ensures that the temporal profiles of the arc exit times are
invertible. Moreover, the FIFO rule applies also to the entrance times.
, for all t > t (30)
Any arc aA consists of a homogeneous channel with two bottlenecks located at the beginning
and at the end. The flow states along the arc are determined on the basis of the Simplified
Theory of Kinematic Waves (STKW), assuming the concave parabolic-trapezoidal
fundamental diagram depicted in illustration 123, expressing the vehicle flow q
a
(x,) at a given
section x of the arc and instant t, as a function of the vehicle density k
a
(x,) at the same section
and instant.
The arc is then characterized by:
L
a
Length of arc a
Q
a
Capacity of the initial bottleneck and of the homogeneous channel associated with arc a, called
in-capacity;
S
a
Capacity of the final bottleneck associated to arc a, simulating the average effect of capacity
reductions at road intersections (i.e. due to the presence of traffic lights), called out-capacity S
a

Q
a
;
V
a
Maximum speed allowed on arc a, called free flow speed in VISUM
KJ
a
Maximum density on arc a called jam density
(x, y)A(k)
dZ oN
time
x
y
time
T
k
() = T
h
(t
a
())
t
a
()
hK
xd
kK
od
C
h
(t
a
()) c
a
()
C
k
() = c
a
() + C
h
(t
a
())
a = (o, x)A(k)
(x, y)A(k)
dZ oN
time
x
y
time
T
k
() = T
h
(t
a
())
t
a
()
hK
xd
kK
od
C
h
(t
a
()) c
a
()
C
k
() = c
a
() + C
h
(t
a
())
a = (o, x)A(k)
( ) ( )
a
t '
a
t >
( ) ( )
1
xy
t '
1
xy
t

>
373 PTV AG
Within this framework, for links the in-capacity corresponds to the physical mid-block capacity,
whereas out-capacity reflects the bottleneck capacity imposed by the signal control or priority
rules at the downstream junction. Exit connectors (x, d)A: xN \ Z, dZ are arcs with infinite in-
capacity, entry connectors (o, y)A: oZ, yN \ Z are arcs with infinite out-capacity. Turns,
however, are represented by arcs having zero length and in-capacity equal to their out-
capacity.
Illustration 123: The adopted parabolic-trapezoidal fundamental diagram, expressing the relation among
vehicular flow, speed and density along a given arc.
In illustration 123, k2
a
k1
a
is assumed, implying the following relation among the above
parameters:
Based on the fundamental diagram, it is possible to identify two families of flow states.
Hypocritical flow conditions, corresponding to uncongested or slightly congested traffic.
Under these conditions, if vehicular density increases, the vehicular flow increases also.
Hypercritical flow conditions, corresponding to heavily congested traffic. Queues and
stop and go phenomena occur. Under these conditions, if vehicular density increases, the
vehicular flow decreases.
Then, ko
a
(q) and vo
a
(q) express the density and the speed as functions of the flow in presence
of hypercritical flow conditions, while ku
a
(q) and vu
a
(q) express the density and the speed as
functions of the flow in presence of hypocritical flow conditions.
When modeling arcs with low speed limits, i.e. representing urban roads, it may be assumed
that the vehicle speed under hypocritical flow conditions is constant and equal to the speed
limit, until capacity is reached. In this case, the simpler trapezoidal fundamental diagram
W
a
propagation speed of hypercritical flow states on arc a, called hypercritical kinematic wave
speed.
2 1
a a
a a
KJ Q
V W

374 PTV AG
depicted in illustration 124 may be adopted, where, in order to guarantee k2
a
k1
a
, the
following relation must apply:
Illustration 124: The trapezoidal fundamental diagram suggested for urban links
In order to implement the proposed models, the period of analysis [0, Q] is divided into n time
intervals identified by the sequence of instants
t
= {
0, ,
t, ,
t
n}, with
0
= 0,
i
<
j
for all 0
i < j n, and
n
= Q. For computational convenience, we introduce also an additional instant
n+1
= .
In the following we approximate the temporal profile g() of any variable through either a
piecewise linear or a piecewise constant function, defined by the values g
i
= g(
i
) taken at each
instant
i
. This way, any temporal profile g() can be then represented numerically through
the vector g = (g
0
, , g
i
, , g
n
).
5.18.4 Network performance model
To represent the spillback phenomenon, we assume that each arc is characterized by two
time-varying bottlenecks, one located at the beginning and the other one located at the end,
called entry capacity and exit capacity respectively.
The entry capacity, bound from above by the in-capacity, is meant to reproduce the effect of
queues propagating backwards on the arc itself, which can reach the initial section and can
thus induce spillback conditions on the upstream arcs. In this case the entry capacity is set to
limit the current inflow at the value which keeps the number of vehicles on the arc equal to the
storage capacity currently available. The latter is a function of the exit flow temporal profile,
since the queue density along the arc changes dynamically in time and space accordingly with
the STKW. Specifically, the space freed by vehicles exiting the arc at the head of the queue
takes some time to become actually available at the tail of the queue, so that the jam density
times the length is only the upper bound of the storage capacity, which can be reached only if
the queue is not moving.
The exit capacity, bound from above by the out-capacity, is meant to reproduce the effect of
queue spillovers propagating backwards from the downstream arcs, which may generate
1 1
a a
a a
KJ Q
V W

flow
density
W
a
-Q
a
/ W
a
V
a
Q
a
/ V
a
k1
a
KJ
a
Q
a
q
k2
a
vo
a
(q)
ko
a
(q) ku
a
(q)
hypocritical flow conditions hypercritical flow conditions
flow
density
W
a
-Q
a
/ W
a
V
a
Q
a
/ V
a
k1
a
KJ
a
Q
a
q
k2
a
vo
a
(q)
ko
a
(q) ku
a
(q)
hypocritical flow conditions hypercritical flow conditions
375 PTV AG
hypercritical flow states on the arc itself. For given arc inflows, arc outflows and intersection
priorities, which are here assumed proportional to the mid-block capacities, the exit capacities
are obtained as a function of the entry capacities based on flow conservation at the node.
The network performance model is specified here as a circular chain of three models, namely
the exit flow and travel time model for time-varying capacities, the entry capacity model, and
the exit capacity model, which are solved iteratively. The three models display illustration 125
in the context. The journey times which result from the solution of the three feed back model
components, are combined with the monetary costs to generalized costs by an Arc Cost
Model.
Illustration 125: Scheme of the fixed point formulation for the NPM
Exit flow and travel time models for time-varying exit capacity
Under the condition that the FIFO rule applies and vehicles are therefore not able to overtake,
an arc performance model with time-varying exit capacity is introduced in this section. The exit
flow is achieved by propagating the inflow temporal profile along the arc and thus calculating
the corresponding time-series of the travel time.
Assuming that the capacity at the end of a given edge aA is not reduced due to spillback
effects, for a vehicle entering the edge at time , the hypocritical exit time r
a
()can be
expressed, dependant of the previous part of the inflow time series, which corresponds to the
inflow f
a
() at any time .
(31)
Equation (31) is described below.
for the trapezoidal fundamental diagram (see "Hypocritical exit time model for a trapezoidal
fundamental diagram" on page 377) (illustration 124)
for the parabolic fundamental diagram (see "Hypocritical exit time model for a parabolic
fundamental diagram" on page 377) (illustration 123)
If, however, at the end of the edge there is a bottleneck with a time-varying capacity
a
() S
a
for each time , the time series of the cumulative outflow is determined, whose value E
a
() at
time t is defined as follows.
arc inflows
arc outflows
network
performance model
arc exit flows
exit flow and travel time model
entry capacity model
arc travel times
exit capacity model
arc entry capacities
in- capacities
out-capacities
arc costs
arc cost model
arc exit capacities
arc inflows
arc outflows
network
performance model
arc exit flows
exit flow and travel time model
entry capacity model
arc travel times
exit capacity model
arc entry capacities
in- capacities
out-capacities
arc costs
arc cost model
arc exit capacities
( ) ( ) ( ) = :
a
f
a
r
a
r
376 PTV AG
(32)
where
a
() denotes the cumulative exit capacity at time t.
(33)
This means that
a
() -
a
() vehicles can exit the edge between times and .
The above expression (32) is based on the following specification of the FIFO rule, stating that
the cumulative exit time at the exit instant t
a
() of a vehicle that enters the arc at t is equal to
the cumulative inflow at time t. This means the following:
(34)
Then, equation (32) can be explained as follows: If there is no queue at a given time t, the travel
time is equal to the hypocritical travel time, so that, based on the FIFO rule (34), the cumulative
exit flow r
a
-1
() is equal to the cumulative inflow at time r
a
-1
() when a vehicle that enters the
arc at time is leaving it at t. If a queue develops at time s < t, the exit flow from this point of time
to the time where the queue breaks up, then corresponds to the exit capacity. Based on the
FIFO rule, this results in a cumulative exit flow E
a
() from the cumulative inflow at time r
a
-1
()
plus the integral value of the exit capacity between and t, which is
a
() -
a
().
By definition, the exit flow e
a
() from arc a at time t is:
(35)
By definition, e
a
()
a
() applies at any time t and hypercritical exit flows occur e
a
() =
a
().
Knowing the cumulative inflow and exit flow temporal profiles, the FIFO rule (34) yields an
implicit expression for the arc exit time temporal profile.
(36)
illustration 126 depicts a graphical interpretation of equation (36), where the time profile of the
cumulative exit flow E
a
() complies with the lower envelope of the following curves:
a) the cumulative inflow F
a
(), shifted forward in time by the hypocritical travel time r
a
() -
thus yielding the temporal profile F
a
[r
a
-1
()]. This represents the rate at which vehicles
entering the arc arrive at its end.
b) for every time s, the cumulative time series of the exit capacity is shifted vertically so that
it goes through the point (,F
a
[r
a
-1
()]). This represents the rate of vehicles that can exit the
arc following time s. No queue is present when curve a) prevails. Queuing starts, when the
cumulative exit flow curve falls below the time-shifted cumulative entry flow curve, this
means that more vehicles arrive at the final section of the arc than can exit. In the diagram,
therefore, the queue arises at time s''. In the illustration 126, the calculation of the exit time
based on the cumulative inflow and exit flow temporal profiles is shown using thick arrows.
( ) ( ) ( ) ( )

= :
a a
1
a
r
a
F min
a
E
( ) ( ) d
a a
( ) ( ) ( )
a
F
a
t
a
E =
( ) ( ) d / r
a
dE
a
e =
( ) ( ) ( )
( )
{ } { }

a
F
a
E : min ,
a
r max
a
t = =
377 PTV AG
Illustration 126: Arc with time-varying capacity
Hypocritical exit time model for a trapezoidal fundamental diagram
If the trapezoidal fundamental diagram is adopted to represent flow states on the arc, the
hypocritical speed on the link is constant, and thus equation (27) is simply specified as follows.
(37)
In this case, using (37) equation (32) can be made explicit as follows:
(38)
Hypocritical exit time model for a parabolic fundamental diagram
If the parabolic fundamental diagram is adopted, the situation becomes more complicated
because vehicles may travel at different speeds even at hypocritical densities. If the arc inflow
temporal profile is piecewise constant, the running link exit time can be determined at least
approximately from the STKW. The general idea is to trace out the trajectory of a vehicle
entering arc a at time t, observing the different speeds it will encounter along the arc, and
determining its exit time t
a
(). Since it can result in a large computational effort, we then replace
it with a simpler model which averages traffic conditions and thus limits the number of different
traffic situations encountered by any vehicle on the arc. Readers who would like to get a
general feel for the model as a whole may just note the general idea and skip to the conclusion
of this section. (see "Input and output attributes of the dynamic user equilibrium (DUE)" on
page 390).
( )
a
V /
a
L
a
r + =
( ) ( ) ( ) ( ) { } + = :
a a V / a
L
a
F min
a
E
a
378 PTV AG
Illustration 127: Flow pattern given by the Simplified Theory of Kinematic Waves
Based on the STKW, vehicles change their speeds instantaneously. As depicted in
illustration 127, when the inflow temporal profile is piecewise constant, vehicle trajectories are
piecewise linear. Furthermore, the space-time plane comes out to be subdivided into flow
regions characterized by homogeneous flow states and delimited by linear shock waves. The
slope W
a
ij
of the shockwave separating the two hypocritical flow states (f
a
i
) and (f
a
j
) is:
(39)
In theory, given a piece-wise constant inflow time series, it is possible to determine the
trajectory of a vehicle entering the arc at instant t, and thus its hypocritical exit time r
a
().
illustration 127 shows that it may be extremely cumbersome to determine these trajectories, in
fact.
Many shockwaves may be active on the arc at the same time.
Shockwaves may be generated either at the initial section by flow discontinuities at times
i
, 0 i n-1, or by shockwave intersections on any arc section at any time.
A vehicle may cross many shockwaves while traveling on the arc, and all the crossing
points have to be explicitly evaluated in order to determine its trajectory.
In order to overcome these difficulties, as depicted in illustration 128, we assume that at each
instant r
i
, 0 i n-1, a fictitious shockwave is generated on the initial arc section separating the
( ) ( )
( ) ( )
j i
ij i j a a
a a a a a a
j i
a a a a
f f
W vu f vu f V
ku f ku f
= = +
379 PTV AG
actual flow state (f
a
i+1
) from a region with the average speed
i
= L / (r
a
i
-
i
) of the vehicle
that reaches the arc at time
i
.
Fictitious shockwaves are very easy to deal with due to the following reasons:
They never meet each other, and thus are all generated on the current initial link section
only at time
i
, 0 i n-1.
Each vehicle meets at the most the last generated fictitious shockwave, so that its trajectory
is very easy to be determined.
Based on (35), the slope W
a
i
of the fictitious shockwave is as follows:
(40)
Illustration 128: Flow pattern given by the Averaged Kinematic Wave model
Note that the trajectory of a vehicle entering the current link at time (
i-1
,
i
] is directly
influenced only by the mean trajectory of the vehicle entered at time
i-1
, which synthesizes the
previous history of flow states on the link.
The approximation introduced has little effect on the model efficacy. Moreover, it satisfies the
FIFO rule, which is still ensured between the arc initial and final sections, while local violations
that may occur within intermediate sections are of no interest.
Based on the above, the hypocritical travel time
a
i
=
a
()
i
, 0 i n-1 can be specified as
follows:
a) If a vehicle entered at time
i
does not meet the fictitious shockwave W
a
i-1
before the end
of the arc, its hypocritical exit time is simply:
,
1
( )
i i i
a a a
W vu f V
+
= +
time
L
a
0

2

3
1

4
f
a
1
f
a
2
f
a
3 f
a
4
fictitious shockwaves
average trajectory of the vehicle entering the running link at time
i
, , 0 i n-1
outflow profile
f
a
5
5
W
a
0
W
a
1
W
a
2
W
a
4
W
a
3
0
vu
a
1
vu
a
2
1
inflowprofile
4
space
( )
i i i
a a a a
r L vu f = +
380 PTV AG
Here, f
a
i
is the arc inflow during time interval (
i-1
,
i
].
b) Otherwise, its hypocritical exit time is determined on the basis of the two speeds it
assumes before and after crossing the fictitious shockwave.
,
where
i
is the travel time of the vehicle before it reaches the fictitious shockwave
(illustration 129).
.
Illustration 129: Determination of the arc hypocritical exit time
Then, the hypocritical travel time r
a
() specifying (31) is:
(41)
Entry capacity model
In this section we propose a new approach to represent the effect on the entry capacity of
queues that, generated on the arc final section by the exit capacity, reach the arc initial section,
thus inducing spillback conditions. This part of the model is used only, if DUE is run with the
spillback option activated (see User Manual, Chpt. 5.5, page 883). If the option is turned off,
the storage capacity of an arc is assumed to be infinite, and the entry capacity of a link is never
reduced below the in-capacity.
To help understand let us assume, for the moment, that the queue is uncompressible, that
means, only one hypercritical density exists. Then, the kinematic wave speed is infinitive
from either illustration 123 or illustration 124 it is clear that w
a
= with KJ
a
= k2
a
so that any
hypercritical flow state occurring at the final section would back-propagate instantaneously.
This circumstance does not imply that the queue reaches the initial section instantaneously.
There, the exiting hypercritical flow state does actually not affect the entering hypocritical flow
state until the arc has filled up completely. This means, that the cumulative number of vehicles
that have entered the arc equals the number of vehicles that have exited the arc plus the
storage capacity. The latter in this case is constant in time and given by the arc length
( )
1
( )
i i i i i i
a a a
r L vu f

= + +
1 1 1
( ) ( ( ) )
i i i i i i
a a a
W vu f W

=
time
i-1
W
i-1 vu(f
a
i
)
i
s
p
a
c
e
L
i
r
a
i
i-1

i-1
r
a
i-1
time
i-1
W
i-1 vu(f
a
i
)
i
s
p
a
c
e
L
i
r
a
i
i-1

i-1
r
a
i-1
( ) 1 n i 0 ,
1 i
,
i
,
i 1 i
/
i
a
r
1 i
a
r
i i
a
r
a
r
+ =
381 PTV AG
multiplied by the maximum queue density. As soon as the queue exceeds the arc length, the
entry capacity becomes equal to the exit capacity, that means, all vehicles on the arc move as
one rigid object.
In reality, hypercritical flow states may actually occur at different densities. Their kinematic
wave speeds are not only lower than v0, implying that the vehicles will reach the first arc
section with a delay when starting from the final section, but also somewhat different from each
other, which generates a distortion in their forward propagation in time. Notice that the
fundamental diagrams adopted here are capable of representing the dominant delay effects
but not the distortion effects, since all backward kinematic waves have the same slope.
The spillback effect on the entry capacity is investigated by exploiting the analytical solution of
the STKW. The flow state occurring on an arc section is the result of the interaction among
hypocritical flow states coming from upstream and hypercritical flow states coming from
downstream. Specifically, on the initial section, the one flow state coming from upstream is the
inflow, while the flow states coming from downstream are due to the exit capacity and can be
determined by back-propagating the hypercritical portion of the cumulative exit flow temporal
profile, thus yielding what we refer to as the maximum cumulative inflow temporal profile.
According to the Newell-Luke minimum principle, the flow state consistent with the spillback
phenomenon occurring at the initial section is the one implying the lowest cumulative flow.
Therefore, when the cumulative inflow equals or overcomes the maximum cumulative inflow,
so that spillback actually occurs, the derivative of the latter temporal profile may be interpreted
as an upper bound to the inflow. This enables the determination of the proper value of the entry
capacity that maintains the queue length equal to the arc length.
The instant
a
() when the backward kinematic wave generated at time on the final section
of arc aA by the hypercritical exit flow e
a
() =
a
() would reach the initial section is given as
follows.
(42)
By definition the points in time and space constituting the straight line trajectory produced by a
kinematic wave are characterized by a same flow state. Moreover, illustration 130 shows that
the number of vehicles encountered by the hypercritical wave relative to the exit flow q for any
infinitesimal space ds traveled in the opposite direction is equal to the time interval ds
multiplied by that flow. Therefore, integrating along the arc from the final
to the initial section, we obtain the maximum cumulative flow H
a
() that would be observed at
time
a
() in the initial section as:
H
a
() = (43)
( ) ( ) ( )
a
e
a
w /
a
L
a
+ =
( ) ( ) [ ] q
a
w / 1 q
a
v / 1 +
( ) ( ) ( ) ( ) ( ) ( ) [ ]
a
e
a
w / 1
a
e
a
v / 1
a
L
a
e
a
E + +
382 PTV AG
Illustration 130: Trajectories of a hypercritical kinematic wave and of the intersecting vehicles
In the fundamental diagrams adopted here, the hypercritical branch is linear and therefore
a
() is invertible. Since w
a
(q) = w
a
, the time at
a
() = is = - L
a
/w
a
- based on (42).
Furthermore, H
a
() = E
a
() + L
a
KJ
a
results -based on (43) q/v
a
(q) = KJ
a
- q/w
a
. Therefore, the
maximum cumulative inflow G
a
() that could have entered the arc at time t due to the inflow
volume is given by the following equation:
(44)
If the cumulative inflow F
a
() at time t equals or exceeds the maximum cumulative inflow G
a
(),
so that spillback occurs at that instant, then the entry capacity
a
() is given by the derivative
dG
a
()/d of the latter; otherwise, it is equal to the in-capacity Q
a
.
Differentiating G
a
() implies the following:
=
From e
a
( - L
a
/w
a
) , the following applies:
(45)
illustration 131 shows how, based on equation (44) the time series of the maximum cumulative
inflow can be obtained graphically through a rigid translation (thick arrows) of the cumulative
exit flow time series for L
a
/ w
a
in time and for L
a
KJ
a
in value. Moreover, it points out that, if
G
a
() is greater than F
a
(), the queue is shorter than L
a
and
a
() = Q
a
.
Otherwise spillback occurs and
a
() =
a
( - L
a
/w
a
).
space
time
w
a
(q)
ds / w
a
(q) ds / v
a
(q)
v
a
(q)
ds
kinematic wave
vehicles
space
time
w
a
(q)
ds / w
a
(q) ds / v
a
(q)
v
a
(q)
ds
kinematic wave
vehicles
G
a
( )
E
a

L
a
w
a
------

L
a
KJ
a
if e
a

L
a
w
a
------

+
a

L
a
w
a
------

=
otherwise
=
( ) d /
a
dG ( )
a
w /
a
L
a
e
a
( )

a

L
a
w
a
------

if G
a
( ) F
a
( )
Q
a
otherwise
=
383 PTV AG
Illustration 131: Graphical determination of the time series of the inflow capacity in the case of triangular
fundamental diagram, piecewise constant inflow, and constant exit capacity
Exit capacity model
In this section we present a model to determine, for a given node, the exit capacities of the
upstream arcs, on the basis of the entry capacities of the downstream arcs and of the turn
volumes. Only two node forms occur in the graph that is formed on the basis of the VISUM
network. These are joining links and diverging links. In this case, the model can be described
by the inflows and outflows of edges.
When considering joining links xN, that is an intersection with a singleton forward edge, the
problem is to split the entry capacity
b
() of the edge b = FS(x) available at time t among the
edges belonging to its backward edge, whose outflows compete to get through the
intersection. In principle, we assume that the available capacity is partitioned proportionally to
the out-capacity S
a
of each arc aBS(x). But this way it may happen that on some arc a the
outflow
a
() is lower than the share of entry capacity assigned to it, so that only a lesser
portion of the latter is actually exploited. The rest of the entry capacity is then partitioned
among the other arcs. Moreover, when no spillback phenomenon is active, the exit capacity
a
() is set equal to the out-capacity S
a
.
L
a
/ V
a
L
a
/ w
a
L
a
KJ
a
hypercritical exit flow
spillback
time
time
flow
vehicles
Q
a
a
inflow F
a
(), f
a
()
exit flow E
a
(), e
a
()
a
()
entry capacity
a
()
' ''
L
a
/ V
a
L
a
/ V
a
L
a
/ w
a
L
a
KJ
a
hypercritical exit flow
spillback
time
time
flow
vehicles
Q
a
a
inflow F
a
(), f
a
()
exit flow E
a
(), e
a
()
a
()
entry capacity
a
()
' ''
L
a
/ V
a
384 PTV AG
When considering diverging links xN , that is an intersection with a single backward edge,
the exit flow of this edge a = BS(x) is determined by the most restrictive entry capacity among
the forward edges. If no arc is spilling back, the exit capacity is set equal to the out-capacity. If
only one arc bFS(x) is spilling back, that is f
b
()
b
(), then the exit capacity
a
() scaled by
the share of vehicles turning on arc b is set equal to the entry capacity of b in order to ensure
capacity conservation at the node while satisfying the FIFO rule
a
() f
b
() /
a
() =
b
()
applied to the vehicles exiting from arc a. If more than one arc bFS(x) is spilling back, the exit
capacity is the most penalizing among the above values. On this basis, the following equation
is derived:
(46)
Note that, in contrast with the models presented in the previous two sections, this model is
spatially non-separable, because the exit capacities of all the arcs belonging to the backward
star of a same node are determined jointly, and temporally separable, because all relations
refer to a same instant.
It is assumed that vehicles do not occupy the intersection if they cannot cross it due to the
presence of a queue on their successive arc, but wait until the necessary space becomes
available. Indeed, this model is not capable of addressing the deterioration of performances
due to a misusage of the intersection capacity.
Arc Cost Model
The cost for vehicles entering arc a at time t is given as follows:
(47)
Here, m
a
() describes the monetary costs and the value of time.
5.18.5 Assignment of the network demand (network loading)
In this section we develop a formulation for the dynamic Network Loading Map with implicit
path enumeration in the case of deterministic route choice model. To this end, we will firstly
define and address the continuous dynamic shortest path problem, which lies at the heart of
the route choice model.
Continuous dynamic shortest path problem
Contrary to the static case, in the dynamic context the shortest path problem involves explicitly
the time dimension, since the costs of the arcs constituting a path are to be evaluated at
different instants, consistently with the travel times experienced along the path, as induced by
the recursive equation (28). Then the minimum cost w
o
d
() between each node oN and a
given destination dZ are determined for users departing at time t.
w
o
d
() = min{C
k
(): k K
od
} (48)
It can be proved that the following dynamic version of the Bellman relation for each node oN
(illustration 132) is equivalent to problem (48).
w
o
d
() = min (49)
( ) ( ) ( ) ( ) ( ) ( ) ( ) { }
b b
f , x FS b :
b
f /
a
u
b
;
a
S min
a
=
( )
( )
( ) ( )

a
m
a
t
a
c +
=
{ ( ) ( ) ( ) } ( ) } o FS x :
ox
t
d
x
w
ox
C +
385 PTV AG
Illustration 132: Dynamic version of the Bellman relation
The set of Bellman relations (49) can be solved using a dynamic programming approach
described below.
Path choice and network flow propagation models
Under the assumption that users are perfectly informed rational decision-makers, the resulting
behavior is such that only shortest paths are utilized. The deterministic route choice model for
users that travel between the origin N and the destination Z departing at time t, can then be
formulated through the following extension of the dynamic case of Wardrops first principle:
If path k K
od
is used, i.e., its choice probability P
k
() is positive, then its cost C
k
() is equal
to the minimum cost w
o
d
(), to travel from o to d departing at time t.
vice versa, if path k is unused, i.e., its choice probability is zero, then its cost may not be
smaller than the minimum cost.
This can be formally expressed as follows:
(50)
Moreover, the choice probabilities must be non-negative and amount to 1.
We now develop a formulation based on implicit path enumeration for the route choice model
and for the corresponding network flow propagation model adopting the temporal-layer
approach, where the temporal perspective is the exit time from the current node.
If the shortest paths from N to Z for users departing at time t involve more than one arc
exiting from an intermediate node x, then the conditional probabilities of these arcs at time t for
users directed to d could depend, in general, on the sub-path utilized from each o to x. Because
of the additive nature of arc costs, we assume instead that the arc conditional probabilities at
each node are equal for all users directed to the same destination regardless of the sub-path
so far utilized.
Under this assumption, the choice probability P
k
() of a path k K
od
from oN to dZ for users
departing at time t is equal to the product of the conditional probabilities of its arcs A(k), each
of them referring to the time when these users enter the arc when traveling along the path. The
choice probability of k can be then retrieved through the following recursive expression:
c
ox
() + w
x
d
(t
ox
())
dZ
oN
(o, x)FS(o)
xN
t
ox
()
c
ox
() + w
x
d
(t
ox
())
dZ
oN
(o, x)FS(o)
xN
t
ox
()
( ) ( ) ( ) . 0
d
o
w
k
C
k
P =

386 PTV AG
(51)
where (o, x) is the first arc of k and h K
xd
is the rest of path k.
The dynamic Wardrop condition is satisfied when the conditional probabilities of the edges are
calculated as follows.
(52)
(53)
(54)
Equation (48) states that road users exiting at time t from node oN and directed to the
destination dZ may choose among the forward star FS(o) only an arc (o, x) for which the cost
C
ox
() plus the minimum cost w
x
d
(t
ox
()) to reach the destination once entered x at time is equal
to the minimum cost w
o
d
(). In x, the passage time is t
ox
() here.
The flow f
ox
d
() of vehicles directed to destination dZ that enter the arc (o, x)A at time t is
given by the arc conditional probability p
ox
d
() multiplied by the flow exiting from node o at time
t. The latter is given, in turn, by the sum of the outflow u
yo
d
() from each arc (y, o)BS(o)
entering o, and of the demand flow D
od
() from o to d.This results in the following equation:
(55)
Applying the FIFO and flow conservation rules, the outflow from y at time can be expressed
in terms of the inflow at a at time t
yo
-1
().
(56)
where the weight dt
yo
()/d stems from the fact that travel times vary over time, so that users
exit from y at a certain rate and, in general, enter in o at a different rate, which is higher than
the previous one, if the arc travel time is decreasing, and lower, otherwise.
The total inflow and outflow of arc (o, x)A at time t are then:
(57)
5.18.6 The overall model
All the components of the dynamic user equilibrium procedure have been introduced. Here we
formulate the user equilibrium, where no user can reduce his perceived travel cost by
unilaterally changing paths, described as a fixed point problem in the temporal profiles of the
arc inflows and outflows.
( ) ( ) ( ) ( )
ox
t
h
P
d
ox
p
k
P =
( ) ( ) ( ) ( ) ( ) 0
d
o
w
ox
t
d
x
w
ox
C
d
ox
p =
+
( ) ( )
( ) 1
d
ox
p
o FS x , o
=

( ) 0
d
ox
p
( ) ( ) ( )
( ) ( )
( )

+ =
d
yo
u
o BS o , y od
D
d
ox
p
d
ox
f
( ) ( ) ( ) ( ) [ ] d /
yo
dt /
1
yo
t
d
yo
f
d
yo
u

=
( ) ( ) ( ) ( )
d
ox Z d ox
d
ox Z d
u u ; f ox
f

= =
387 PTV AG
The deterministic case
The formulation of the implicit path enumeration yields the model depicted in illustration 133.
Illustration 133: Variables and models of the fixed point formulations for the network performance model
(left hand side) and for the dynamic assignment with spillback (right hand side)
In analogy with the static case, the Network Loading Map (NLM) is a functional relation
yielding, for given demand flows D, an arc flow pattern f consistent with the arc performances
t, and c, through the deterministic route choice model p(w(c, t), t, c), and the network flow
propagation model (p, t; D). The assignment uses an implicit path enumeration and is based
on the minimum costs w from each node to destination, as well as on the resulting conditional
probabilities p of the edges. In turn, the arc performance model yields the arc exit time pattern
t, and the arc cost pattern c, consistent with the arc inflows f and arc outflows u. The
deterministic equilibrium results from the feedback of network loading map and arc
performance model.
arc performance function
p(w, c, t)
D
(p, t ; D)
c(t)
f, u t c
w
w(c, t)
network loading map
*( f, u)
E( f, )
E
t( f, u, E)
( f, E, ; Q)
(f, u, ; S)
network
performance model
Q
S
f, u
E
E( f, )
p
arc performance function
p(w, c, t)
D
(p, t ; D)
c(t)
f, u t c
w
w(c, t)
network loading map
*( f, u)
E( f, )
E
t( f, u, E)
( f, E, ; Q)
(f, u, ; S)
network
performance model
Q
S
f, u
E
E( f, )
p
388 PTV AG
The Probit case
In the Probit route choice model, which is based on the random utility theory, the arc costs
perceived by users are not known with certainty and are thus regarded as independent random
variables. We extend the Probit model to the dynamic case assuming that the arc cost
a
() of
arc aA perceived by users at time t is equal to the sum of the arc cost c
a
() yielded by the arc
performance model and of a time-varying random error, whose value at time t is distributed as
a normal variable. Its variance is assumed proportional to a time-varying cost term
a
() > 0
and independent of the load case.
The arc flow pattern resulting from the evaluation of the Probit NLM for given arc performances
is obtained through the well-known Montecarlo method as follows:
1. Get a sample of perceived arc cost patterns:
Applies in compact form
(58)
where each
a
() is extracted from a standard normal variable N[0.1] and h = 1, , H..
2. For each perceived arc cost pattern of the sample, determine with the deterministic NLM a
consistent arc inflow pattern.
3. Calculate the mean of the resulting deterministic arc inflow patterns, thus obtaining an
undistorted estimation of the Probit arc inflow pattern.
Note that, based on equation (58), the entire time series is disturbed by just one
random number. This means, that the error of estimation of road users does not depend on the
time of day. This is consistent with the behavior of users, who perceive the arc cost temporal
profile as a whole. On the contrary, the travel times that underlie the network flow propagation,
are considered as constant throughout the simulation.
5.18.7 Example of the Dynamic user equilibrium
In order to investigate the behavior of the proposed model and to show the effect of spillback
on path choice, we analyze a simple example which presents intuitive solutions. It is located in
the folder Examples\DUE of your VISUM installation as Braess_without_spillback.veR and
braess_with_spillback.ver.
We consider the Braess network depicted in illustration 134. Links have the characteristics
reported in the corresponding table, and are all modeled with a parabolic-trapezoidal
fundamental diagram. All link out-capacities are set equal to the corresponding in-capacities.
The turn capacities are Q
AC
= Q
AE
= Q
ED
= 2,000 veh/h and Q
BD
= Q
CF
= Q
DF
= 1,000 veh/h.
( ) ( ) ( ) [ ]
5 . 0
a
h
a a
c
h
a
c
+ =
( ) ; c c
h
c
=
( )
h
c
a
Link L
a
[km] Q
a
[veh/h] V
a
[km/h] W
a
[km/h] 1 / K
a
[m]
A 0.4 2000 50 15 7.0
B 0.6 2000 50 15 7.0
C 0.6 2000 50 15 7.0
389 PTV AG
The assignment period is constituted by 100 intervals of 1 minute. We assume a constant
demand for the first 33 minutes of simulation from node 1 to node 5 equal to D
15
= 2,300 veh/h.
The outputs of two assignment runs, one without and the other with spillback congestion, are
presented in illustration 135. Without spillback, the congestion is evenly located only on turns
CF and DF (which can be gathered observing turn travel times), so that on all the paths
between node 1 and node 5 the queue is about equal, and path A-E-D-F has fewer users since
it is clearly not convenient. With spillback, however, the queue propagates from turn CF to arc
C and up to arc A, and from turn DF to arc D and up to arcs B and E. Moreover, the spillback
effect is greater on arc B than on arc E because of the different capacities of turn ED and turn
BD. Then, after an initial growth, the travel time on arc D remains constant, since congestion is
propagated upward, while the travel time on arc B grows faster than the travel time on arc E,
so that path A-E-D now becomes competitive, as it implies a longer route but a lower travel
time. That is why the flow on arc E increases from around 150 veh/h to 670 veh/h
approximately.
D 0.4 2000 50 15 7.0
E 0.4 2000 50 15 7.0
F 0.1 4000 50 15 3.5
Link L
a
[km] Q
a
[veh/h] V
a
[km/h] W
a
[km/h] 1 / K
a
[m]
4
A
D
B
C
1
2
3
E
5
F
4
A
D
B
C
1
2
3
E
5
F
DUE without spillback - inflow [veh/h]
0
500
1000
1500
2000
0 500 1000 1500 2000 2500 3000 3500
arc A
arc B
arc C
arc D
arc E
arc A
arc B
arc C
arc D
arc E
390 PTV AG
Illustration 135: Results of WDDTA without and with spillback
5.18.8 Input and output attributes of the dynamic user equilibrium (DUE)
This method computes an equilibrium assignment over a given assignment period, given both
time-varying demand and time-varying supply.
Input Supply
The available network is defined as usual by nodes, links, turns, zones, and connectors
(optionally also main nodes and main turns). The attributes listed in Table 130 are relevant for
DUE.
DUE with spillback - inflow [veh/h]
0
500
1000
1500
2000
0 500 1000 1500 2000 2500 3000 3500
arc A
arc B
arc C
arc D
arc E
arc A
arc B
arc C
arc D
arc E
DUE without spillback travel time [sec]
0
50
100
150
200
250
300
0 500 1000 1500 2000 2500 3000 3500
turn AC
turn BD
turn CF
turn DE
turn ED
turn AC
turn BD
turn CF
turn DE
turn ED
DUE with spillback travel time [sec]
0
50
100
150
200
250
300
0 500 1000 1500 2000 2500 3000 3500
arc A
arc B
arc C
arc D
arc E
391 PTV AG
*) MPA only: affecting each OD pair
Some of the attribute can be temporarily restricted. These attributes will then have a default
value, but may assume a different value during a given interval within the assignment period.
The transport system set and the connector shares have the same meaning as in all other
assignment methods.
Impedances are handled in a special way in DUE (see "Network performance model" on
page 374). In particular, link travel time is the sum of t
0
with free flow and a wait time at the
bottleneck which is assumed to be located at the end of the link. The free-running travel time
t0 depends on a flow-density fundamental diagram. The fundamental diagram can have one of
two different shapes which differ in the sub-critical branch, this means, where density is less
than the critical density (at which maximum flow is reached). The shape is defined by the link
attribute DueFunDiag.
In the case of urban links, a trapezium shaped fundamental diagram is recommended. In this
type of diagram, the hypocritical branch is linear, which means that vehicles travel at free-flow
Network object Attribute Optionally time-
varying
Comment
Link TSysSet J
Length N
v0 PrT J
Capacity PrT J in [veh/h]
Toll PrTSys J
DueVWave N See below for explanation
of link impedance
DueFunDiag N
SpacePerPCU N
LinkSpacePerPCU N
Link type vMax PrTSys N Maximum speed per
transport system on any
link of this type
Turns TSysSet J
t0 PrT J
Capacity PrT J in [veh/h]
Main turns TSysSet N
t0 PrT N
Capacity PrT N in [veh/h]
Zones SharePrTOrig/Dest*) N Do connectors have
shares{Yes/No}
Connectors t0_TSys N
Weight*) N Connector share, if
enabled for zone
Table 130: Input attributes for the DUE procedure
392 PTV AG
speed v
0
(on the free-running part) until capacity is reached. illustration 136 illustrates how the
shape of the diagram is determined by the link attributes.
Illustration 136: Shape of the fundamental diagram based on the link attributes
Notice that the jam density is the maximum number of vehicles per 1 km of link length. For a
single-lane link a typical value for SpacePerPCU would be around 7 m, resulting in a jam
density of ~140 vehicles / km.
In order for the fundamental diagram to be well-defined, the sub-critical and hyper-critical
branches must not overlap. Therefore the link attributes must satisfy the condition:
Capacity PrT (1 / v
0
+ 1 / DUEvWAVE) 1.000 / LinkSpacePerPCU.
For freeway links, the assumption of constant sub-critical speed is not always justified, and an
approach similar to volume-delay functions appears more suitable.
In this type of diagram, the sub-critical branch is parabolic (illustration 137), speed decreases
from v
0
at free flow to 0.5 v
0
at capacity and the flow-density curve reaches capacity with zero
derivative. The validity condition for the attributes then becomes
Capacity PrT (2 / v
0
+ 1 / DUEvWAVE) 1.000 / LinkSpacePerPCU.
All other properties are identical to the sub-critical linear case.
DUE fundamental diagram
0
500
1000
1500
2000
2500
0 20 40 60 80 100 120 140 160
Densi ty [veh/km]
F
l
o
w

[
v
e
h
/
h
]
sub-critical
hyper-critical
CapacityPrT
-
D
U
E
v
W
a
v
e
jam density = 1000 / SpacePerPCU
v
0
393 PTV AG
Illustration 137: Parabolic sub-critical branch in the fundamental diagram
The wait time at the end of the link is a function of the bottleneck capacity. This is defined for
each turn by turn attribute Capacity PrT. To work correctly with DUE, turn capacities should
be determined in the following way:
First, determine the saturation capacity of each lane of the upstream arc, as the lane
capacity multiplied by the green time fraction (g/c) corresponding to that lane in the case of
a signalized intersection, or by some suitable multiplier in case of non-prioritized approach
at a non-signalized intersection;
Then, determine each turn capacity as the sum of the capacities of lanes allowed for the
corresponding maneuver.
Note: In case of lanes allowed for more than one maneuver, the corresponding lane capacity
is not to be split among the corresponding turns, but is to be entirely assigned to each turn
corresponding to the allowed maneuvers. In this case in fact, DUE will, based on the turn
flows resulting from WDDTA, internally identify the actual capacity to be assigned to each
turn.
DUE fundamental diagram
0
500
1000
1500
2000
2500
0 20 40 60 80 100 120 140 160
Densi ty [veh/km]
F
l
o
w

[
v
e
h
/
h
]
sub-critical
hyper-critical
CapacityPrT
v
0
-
D
U
E
v
W
a
v
e
zero derivative
jam density = 1000 / SpacePerPCU
v
0
/
2
394 PTV AG
Example
Illustration 138: Signalized intersection in reality
The signalized intersection in illustration 138, with lane capacities = 1800 veh/h, signal cycle =
90 s and green fractions depicted the in VISUM should be implemented in illustration 139 as in
figure below. The turns approaching from the West have the following capacities:
turn 1 (1 lane allowed): Q
1
= 1800 30 / 90 = 600 veh/h
turn 2 (2 lanes allowed): Q
2
= 1800 45 / 90 + 1800 45 / 90 = 1800 veh/h
turn 3 (1 lane allowed): Q
3
= 1800 45 / 90 = 900 veh/h
Whereas the capacity of the right lane, which can be used to go either straight or right, is added
both to the straight turn capacity and to the right turn capacity.
Illustration 139: Diagram of the signalized node in VISUM
Wait time for a turn is the sum of t
0
and a variable part based on volume and Capacity-PrT.
Input Demand
DUE accepts a description of time-varying demand. Like elsewhere in VISUM, this description
can take two possible forms:
Total demand matrix with a demand time profile which assigns percentage shares of
the total matrix to time intervals.
A demand time profile in which each time interval refers to a separate demand matrix.
Note: Note that if you declare turn Capacity-PrT time-varying, you can model the effects of
different green time splits depending on the time of day.
80 m
g = 30 s
g = 45 s
g = 45 s
80 m
g = 30 s
g = 45 s
g = 45 s
Q
1
Q
2
Q
3
links
turns
395 PTV AG
If a calendar has been set, it is ignored. Make sure that the demand profile is defined for day 1
of the calendar period.
DUE is a multi-class assignment method, this means, multiple demand segments, each with its
own demand description, can be assigned in a single run.
Overview of all input attributes
In a overview Table 131 shows all relevant input attributes for DUE .
Table 131: Example of the Dynamic user equilibrium
Output attributes of the Dynamic user equilibrium
The results of the operation are available through link, turn, main turn and connector attributes
for volume and impedance. In particular, volumes are available as totals or by demand
segment or transport system, and in vehicles, PCU, or persons. Both volumes and impedances
are given by analysis time interval.
x2 Toll-PrTSys has to be inserted manually in the impedance function (part of the procedure
parameters) to have an effect
x3 Optionally time-varying
396 PTV AG
The definition of queue lengths as a measure of oversaturation is not easily defined, as in the
DUE model queues may move and only gradually approach the situation where traffic is at a
standstill at queue density. Because queues move (at a speed depending on the hyper-critical
branch of the fundamental diagram), and separation between vehicles (density) is not
constant, it would furthermore be misleading to speak of queue length in meters. Therefore we
adopt a definition which is similar to congestion hits in more microscopic simulations. The
value of the queue length (for a given link and time interval) is the number of vehicles
experiencing hyper-critical delay, i.e. spend more time on the link than the free-running link
travel time resulting from v
0
plus the sub-critical wait time at the bottleneck (e.g. waiting for the
next green time in the cycle).
Table 132 gives an overview of all DUE output attributes.
Table 132: Output attributes of the Dynamic user equilibrium
5.19 Dynamic stochastic assignment
The dynamic stochastic assignment differs from all other PrT assignment procedures as a
result of the explicit modeling of the time required to complete trips in the network. For dynamic
stochastic assignment - capacity has to be set as an hourly value - not regarding the length of
the time interval the demand is available for.
The dynamic stochastic assignment takes time-varying attributes of traversed links, turns,
main turns and connectors into account (t0, tCur, VolCapRatio per time interval, that
result from their temporary attributes, for example, capacity and v0 or t0).
The dynamic stochastic assignment provides the calculated results, for example volume or
impedance of the connections (routes in time interval) and of their traversed network
x1 Totals for assignment period and values per time interval
397 PTV AG
Chapter 5.19: Dynamic stochastic assignment
objects, which means links, turns, main turns and connectors, for each user-defined time
interval. Since the impedance equals the congested travel time in most applications, time
profiles for the assignment period can be generated this way. For the routes, tolls and
AddValues are additionally issued for each time interval.
In contrast, all trips are completed in the case of static assignment procedures with no
indication of the time required, capacities have to be specified according to the length of the
time interval demand data is available for, and the volumes of all trips and the resultant
impedances are superimposed upon each other at the individual network objects. Road-users
subsequently only have to choose from a number of different routes for each journey. The
departure time is irrelevant.
In the case of the dynamic assignment on the other hand, an assignment period T (e.g. 24
hours) is specified and divided up into time slices T
i
of equal length (e.g. 15 minutes). Only the
search for (alternative) routes for each journey is made with no reference to a specific time. As
in the case of the static stochastic assignment, several shortest path searches are completed
with network impedances that vary at random. All other operations explicitly include a time
dimension. As for the stochastic assignment, further random searches may be carried out (see
User Manual, Chpt. 5.6.9.2, page 928).
From the entire demand and its temporal distribution curve, the portion with a desired
departure time is determined for each time slice within this time interval. On the supply side,
there are pairs to choose consisting of route and departure time interval, which, using PuT
assignment terminology, are also called connections. The impedance of a connection is
composed of its network impedance and the difference between the actual and desired
departure time slice (temporal utility). To determine the network impedance, the volume and
the capacity-dependent travel time for each network element are stored separately for every
time slice. The progress time of the trip through the network is decremented along the route,
whereby for each network element the travel time of the time slice(s) in which the network
element is traversed is relevant.
The following illustration 140 shows qualitatively the procedure for calculating the impedances
along the time-path line of the connection.
In this case, S (= faSt) and L (= sLow) represent the capacity-dependent speed of the network
element in the relevant time slice. The correct path of the trip and thus the correct network
impedance of the connection results only when the travel time on each link (B in particular in
this case) is included with respect to the time slice reached at this moment.
398 PTV AG
Illustration 140: Example of the impedance calculation of a connection
After assignment to individual connections, the network elements are loaded with the demand
for each time slice as in the case of the impedance calculation, which results in new network
element impedances. It is assumed that the departure times of the individual trips are equally
distributed within the time slice, this means, instead of a single time-path line, a volume range
is decremented (Example illustration 141).
Illustration 141: Example of the network volume along a connection
Links
Time
A
S
C D
2
3
4
1
S
S
L
S
S
S
S
S
S
S
S
B
0 S S S

A
S
C D
2
3
4
1
S
S
L

S
S
S
S
S
S
S
B
0 S S
Actual path
Travel times on reaching specific link
Travel times at departure time
399 PTV AG
5.19.1 Evaluation of the Dynamic stochastic assignment
The dynamic assignment permits the analysis of the analysis of temporary overload effects in
the network. Depending on the time-dependent capacity, not only are different routes chosen
at different times, but if necessary the actual departure time is shifted with respect to the
desired departure time. The procedure is therefore ideal for calculating distribution curves of
the volume on network objects.
On the other hand, the use of the procedure requires a temporal layering of the demand using
a distribution curve over the assignment period.
5.19.2 Input and output attributes of the dynamic stochastic assignment
To execute the dynamic stochastic assignment, certain entries have to be made. The
Table 133 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
page 1253) . Table 134 lists the output attributes which store the results of the procedure.
Table 133: Input attributes of the dynamic stochastic assignment
400 PTV AG
Table 134: Output attributes of the dynamic stochastic assignment
5.19.3 Procedure of the dynamic stochastic assignment
The procedure in illustration 142 keeps to the sequence of the static stochastic iteration and
differs essentially in the use of substeps on connections instead of on routes. It is broken down
into an external iteration for the connection search and an internal iteration for the connection
choice and network loading.
x1 Totals for assignment period and values per time interval
x2 Toll-PrTSys has to be inserted manually in the impedance function (part of the procedure
parameters) to have an effect
x3 Optionally time-varying
401 PTV AG
n = 0
Start of
external
iteration
Calculate impedance R in unloaded network for all
network objects.
For each time slice T
i
selected in the procedure
parameters:
Calculateone route per OD pair using a shortest path
search with R
n,Ti
. Find more routes by varying R
n,Ti
according to a normal distribution 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 one.
Each pair consisting of route and time slice represents a
connection.
Calculateindependence factor (commonality factor) that
takes into account the relative similarity of the routes
(basis: impedances in the unloaded network) or the
independence(Ben Akiva)
Number of new routes > 0
Delete all connections with R > a R*
min
+ b and
t
0
> c t
0,min
+ d
Counter for
external
iteration
Connection
search
Connection
preselection
Independence
no
Search
impedance
n = n + 1
Termination of
external
iteration
yes
m = 0
Start of internal
iterartion
Set impedance R and R* of all network objects in all time
slices to impedance in the unloaded network.
Initialisation of
choice
impedance
stop
402 PTV AG
Illustration 142: Procedure of the dynamic stochastic assignment
5.20 NCHRP 255
This postprocessor for PrT assignments is an Add-on module used to correct assignment
volumes on links and turns of the forecast by means of a correction factor, which is calculated
on the basis of the differences between traffic counts and an assignment, both representing the
same time slice, as is described in Report 255 (National Cooperative Highway Research
Program).
The procedure comprises the following steps:
1. The count values of the incoming link at the node result from totaling the turn count values
for the corresponding From Link.
Calculate R* of all connections as total R* for all traversed
network objects in each time slice af fected. Increase
impedance using deviation from desired departure t ime
slice and correct using impedance f actor.
Calculate R* f or all network objects in all time slices f rom
the volumes that result from the connection choice. The
search impedance is an estimat ed R* value that is
calculated as in the learning procedure:
m = max. number of internal iterations or
is valid for the impedance of all net work elements in all
time slices, and
is valid for the volume of all connections
Counter for
internal
iteration
Choice
impedance
Rout e volume
Update search
impedance
no
m = m + 1
Termination
criterion for
internal
iteration
yes
Assignment of demand across connections in accordance
with Logit , Box-Cox, Kirchhof f, Lohse or Lohse with
variable beta results in connection volumes q
rm
*
Connection
choice
n = max. number of external iteration
Termination of
external
iteration
no
yes
stop
m
q m q
q
rm m r
rm
' ) 1 (
) 1 (
+
=

( )
*
old new
*
ld
*
new
R R R R
o
+ =
) , ) , max( min(
3 2
*
1
*
1
*
1
*
E E R R E R R
m m m m
+

) , ) , max( min(
6 5 ) 1 ( 4 ) 1 (
E E q q E q q
m r rm m r rm
+

403 PTV AG
Chapter 5.21: Assignment analysis PrT
2. Calculate the difference between the link base count (as input by the user) and the value of
the link base assignment value.
3. Calculate the adjusted link volumes as the future link assigned value + the adjustment
factor.
4. Furness (balance) the new link adjusted volumes to match the counted turn volumes. The
result is turns that add up to the new link volume totals, but that have the percentage split
(or distribution) found in the turn counts. The Furness process is iterative.
5. The postprocessed link and turn volumes are stored in a user-specified link or turn attribute.
5.21 Assignment analysis PrT
Assignment analysis is used for calculating the correlation (Goodness-of-Fit Report) between
calculated and observed attribute values of a selected network object type.
The calculated value is derived from the assignment or the network model.
The observed value may be count data or measured data.
Here are some examples:
Travel time comparisons between PrT and PuT
Travel time comparisons of different scenarios
Calculated and counted volumes (links, turns or main turns)
Calculated and measured speeds
Any numeric input or output attributes of the following network objects can be selected:
Links
Nodes
Turns
Main nodes
Main turns
Lines
Line routes
Screenlines
Time profiles
Paths
Prerequisite is, that the observed values must be >0 for the selected network object type.
You can select which objects you want to include in the assignment analysis. There are three
possibilities:
All objects of the selected network object type
Only active objects
Only objects with observed value > 0
For the assignment analysis, as an option, you can consider user-defined tolerances for user-
defined value ranges of the calculated attribute.
The quality of the correlation can be determined and issued in two ways:
in groups (for each value of the classification attribute)
404 PTV AG
collectively for all included network objects
For the output, the data model of the network object types above has been supplemented with
the calculated attribute Assignment deviation (AssignDev) of type real. Alike all other
VISUM attributes, the attribute can be graphically displayed and issued in lists of the respective
network object.
In addition, VISUM calculates various indicators (per group or collectively) that can be issued
in a list or in a chart.
Table 135 shows the calculation rules for the output attributes of the assignment analysis. To
the formulas applies:
Note: An assignment result is no longer necessary in order to calculate the correlation
coefficient.
Z Observed value (counts or measures)
U Calculated value (assignment or network model)
N Number of objects with observed value > 0
AbsRMSE
Abs RMSE
Absolute root of mean square deviation
Significant differences between counted and modeled values have a higher
impact according to
Intercept
Intercept
Coefficient b in linear regression
Cf. Excel function: Linear Regression (y = ax + b)
ShareAccGEH
Percent with acc GEH
Percentage objects with acceptable GEH value (per network object)
ShareAccRelErr
Percent with avg rel error
Percentage objects within tolerance
NumObs
Number observations
Number of observations per class (objects with observed value > 0)
NumClass
Number in class
Total number (=observed + not observed) objects per class
ClassValue Value of classification attribute (or blank, if not classified)
Table 135: Calculation rules for the output attributes of the assignment analysis
( ) ( ) 2 1
N
1 i
N
2
i
U
i
Z
=
=

( )
( )
( ) 2
i
U
i
Z
2
i
U
i
Z
i GEH
+
=
abs Z
i
U
i
( )
U
i
------------------------------ Tolerancz U ( )
405 PTV AG
Chapter 5.21: Assignment analysis PrT
Corr Correlation coefficient (cf. Excel function Pearson)
Notes
The value range lies between -1 and 1, where the following applies:
-1 = observation opposed to modeling
0 = no correlation (at random)
+1 = very good correlation
The observed/modeled value ratio should be as close to 1 as possible.
If only 2 values > 0 are used, the correlation coefficient is -1 or 1.
From the value of the correlation coefficient, one cannot determine whether all
observed values are higher (or lower) than the calculated values or upward
and downward deviations exist.
MeanAbsE Mean absolute error
Mean deviation of absolute values (a)
(Difference between observed and modeled values)
MeanObs
Mean observed value
AvgRelErr Mean relative error
Mean deviation of absolute values in % (p) according to
R2
Coefficient of determination r
2

Cf. Excel function RSQ
RelRMSE Relative root of mean square deviation
StdDev Standard deviation
Slope Coefficient a in linear regression
Cf. Excel, Linear Regression (y = ax + b)
( ) ( )
=
i
U
i
Z Abs
N
1
a
i
Z
N
1
( )
( )

=
i
Z
i
U
i
Z Abs
p
( )
( )
N
i
Z
1 N
2
i
U
i
Z
406 PTV AG
407 PTV AG
6 User Model PuT
The PuT User Model calculates the effect of PuT supply on PuT passengers.
Subjects
Overview of PuT assignment procedures
Example network for the PuT assignment procedures
PuT paths
PuT skims
PuT impedance functions
Distribution of the travel demand to PuT connectors
Allocation of skims with reference to lines/links
Transport system-based assignment
Headway-based assignment
Timetable-based assignment
Assignment analysis PuT
PuT Passenger surveys
6.1 Overview of PuT assignment procedures
To model PuT trips, VISUM provides three types of PuT assignment procedures which differ in
required input data, accuracy of results, and computing time.
The transport system-based procedure, which is based on a PuT-specific "all or nothing"
assignment, provides an overview of the transport demand structure. This procedure does
not require a line network (see "Transport system-based assignment" on page 428). For
rough-cut planning purposes it helps to determine the "ideal line network" where each
passenger chooses the fastest route in the network without any restrictions caused by PuT
line routes or timetables.
The headway-based procedure is ideal for urban networks with short headways and for
long-term conceptual planning, as long as the timetable for the period being analyzed is still
unknown. The headway-based procedure determines the transfer wait time at transfer
stops from the mean headway of the succeeding lines. If necessary, co-ordination in the
case of transfers between lines and also between the timetables of multiple lines are taken
into consideration on sections with shared services, and then specified deviating transfer
wait times are valid. Doing without the timetable on the level of individual trips ensures short
computing times even for large networks (see "Headway-based assignment" on page 430).
The timetable-based procedure should be used if the PuT supply has long headways
and coordination of the timetable is important for transfers. It takes the accurate timetable
into consideration and is therefore particularly suitable for rural areas or train networks.
There are two variants of the timetable-based procedure, which differ only in terms of the
connection search procedure (see "Timetable-based assignment" on page 452).
408 PTV AG
Chapter 6: User Model PuT
In large networks, a distinction can often be made between a main network, which is the most
important one to be analyzed, and a subordinated network, which provides feeder functions for
the main network. Examples for this are national rail networks with subordinated regional or
urban bus networks, which also include cars or taxis for access and egress. For modeling the
subordinated network, there are basically two alternatives.
Traffic zones that are not served by the main network are nevertheless connected to stops
of the main network by long connectors. This alternative means that planners are required
to estimate the route choice in the subordinated network accurately when selecting and
setting attributes for the connectors. The route choice can also change in the case of
supply changes in the main network.
With regard to modeling accuracy, it is instead recommended to also model the
subordinated network as a PuT supply. In addition to the considerable effort required to
obtain the timetable data, memory requirements and computing time for the assignment
are also greater. Especially in the case of short headways in the subordinated network, the
number of connections explodes.
A compromise solution involves modeling the entire main network and performing either a
headway or a timetable-based assignment. The subordinated PuT supply in comparison is
only modeled as a used link network and in the course of the either headway or timetable-
based assignment it is treated as in the transport system-based procedure (best path search,
see illustration 143).
Illustration 143: Different modeling options for main and subordinated networks
For this kind of modeling, the used links and turns in the subordinated network are opened for
transport systems of the special PuTAux type and provided with specific run times for these
connections. If PuT auxiliary transport systems are not available for all demand segments (for
example car for P+R access), this is expressed by targeted inclusion in the appropriate modes.
The mode for the demand segment Employed with car contains the PuT auxiliary transport
system P+R, but the demand segment Employed without car does not.
The PuT assignment procedures are mainly used for the following applications.
To determine volumes, for example line volumes, link volumes, and the number of
passengers who board, transfer or alight at stops.
To calculate passenger-specific PuT skims, for example journey time, number of transfers,
service frequency.
As a timetable information system which provides information on the departure and arrival
times of individual connections.

S S
PuT with timetable
PuT w/o timetable
409 PTV AG
Chapter 6.2: Example network for the PuT assignment procedures
6.2 Example network for the PuT assignment procedures
The different procedures are described below using an example (illustration 144,
illustration 145, illustration 146, Table 136 and Table 137). The connections between A-Village
and X-City are to be determined from the examples PuT supply.
The following assumptions apply.
The calendar is not used.
Access and egress times are not considered, that is, they are set to 0 minutes.
The analyzed time interval starts at 5:30 a.m. and ends at 7:30 a.m.
Travel demand between A-Village and X-City amounts to 90 trips (Tables $MATRIX and
$MATRIXSINGLELISTITEM in demand data file PuT.dmd).
33% of travel demand, that is 30 trips occur between 5:30 a.m. and 6:30 a.m., the
remaining 67 % or 60 trips are distributed across the period between 6:30 a.m. and 7:30
a.m. (Tables $TIMESERIES and $TIMESERIESITEM in demand data file PuT.dmd).
The Table 136 contains example data of the PuT.dmd file which is provided in English.
410 PTV AG
The example network VISUM115 can be found in the directory ...\\Examples\Example_net.
Version file: Example.ver
Graphic parameters PuT.gpa
OD matrix and demand distribution PuT.dmd
Procedure parameters PuT.par
$VI SI ON
* Vi sumI nst ( 2010- 03- 15)
* 04/ 11/ 07
*
* Tabl e: VERSI ON
$VERSI ON: VERSNR; FI LETYPE; LANGUAGE; UNI T
4, 000; Demand; ENG; KM
* Tabl e: ODMATRI X
$ODMATRI X: NO; CODE; NAME; CONTENT; ROUND; NUMDECPLACES
1; C; Car ; ; 0; 0
2; H; HVeh; ; 0; 0
3; P; PuT; ; 0; 0
* Tabl e: MATRI XSI NGLELI STI TEM
$MATRI XSI NGLELI STI TEM: MATRI XNO; FROMZONENO; TOZONENO; VALUE
1; 100; 200; 2000. 000
2; 100; 200; 200. 000
3; 100; 200; 90. 000
* Tabl e: TI MESERI ESDOMAI NTYPE
$TI MESERI ESDOMAI NTYPE: NO; DESCRI PTI ON; UNI TYSTRI NG; NUMDECPLACES; MAXVALUE; MI N-
VALUE
1; Ti me ser i es by per cent ages; %; 2; 9999999999. 000; 0. 000
2; Ti me ser i es of mat r i x number s; No; 0; 999999999. 000; 0. 000
* Tabl e: Ti me ser i es
$TI MESERI ES: NO; NAME; TYPENO; UNI TX; NUMI NTERVALS; LENGTHI NTERVAL; USEVALUE-
LI ST; VALUELI STTYPE; VALUEREFTYPE; DECSEPARATOR; VALUESEPARATOR
1; ; 1; ; 86400; 1; 0; 0; 2; ;
* Tabl e: Ti me ser i es i t ems
$TI MESERI ESI TEM: TI MESERI ESNO; STARTI NTERVALI NDEX; ENDI NTERVALI NDEX; VALUE
1; 1; 19800; 0. 000
1; 19801; 23400; 33. 000
1; 23401; 27000; 67. 000
* Tabl e: Demand t i me ser i es
$DEMANDTI MESERI ES: NO; CODE; NAME; TI MESERI ESNO
1; ; ; 1
* Tabl e: Demand descr i pt i ons
$DEMANDDESCRI PTI ON: DSEGCODE; DEMANDTI MESERI ESNO; MATRI XNO; STARTDAYI NDEX; START-
TI ME
C; 0; 1; 1; 12: 00 AM: 00
H; 0; 2; 1; 12: 00 AM: 00
P; 1; 3; 1; 12: 00 AM: 00
Table 136: Demand matrix and temporal distribution of demand for the example
411 PTV AG
Chapter 6.2: Example network for the PuT assignment procedures
Illustration 144: Timetable
Illustration 145: Line map
Timetable Bus 1 Timetable Train
A-Village 6:10 6:55 7:25 Station 6:25 7:05 7:45
Station 6:22 7:07 7:37 X-City 6:41 7:21 8:01
B-Village 6:42 7:27 7:57
X-City 6:55 7:40 8:10
Connections
Departure 6:10 a.m., Arrival 6:55 a.m., ride time 45 min., 0 transfer
Table 137: PuT supply of the example with connections from A-Village to X-City
6.00
6.30
7.00
7.30
8.00
Origin Destination
Bus 1
Bus 1
Bus 1
Station
Train Train
Train Train
Train Train
A-Village X-City
B-Village
X-City (destination)
A-Village (Origin)
Station
Bus 1
Train
B-Village
412 PTV AG
6.3 PuT paths
Paths are the central result of an assignment (see "Paths in PrT and PuT" on page 192). In the
timetable-based assignment (see "Timetable-based assignment" on page 452) a PuT path is
described through a sequence of path legs which each represent one of the following activities.
Change of location from one stop point to another by using a specific service trip
Change of location from origin zone via a connector and links to a stop point or from there
to destination zone with a PuT-Walk TSys
Transition from one stop point to another with a PuT-Walk TSys
Change of location by using a PuT-Aux TSys
Because each of the used service trips is known, the path has a time reference (see "Network
objects of the line hierarchy" on page 46). Each of its path legs starts and ends at a precise
time. This is called a connection.
If the option Save paths as connections has been selected for the assignment (see User
Manual, Chpt. 6.1.1.2, page 944), these connections become visible in the PuT path leg list
Alternatively, a path can be described without specifying service trips in detail. In this case only
the time profile is known, which was used for a change of location via a PuT line (see "Network
objects of the line hierarchy" on page 46). The departure and arrival times of each path leg are
then relative times relating to the beginning of the path, completely analog to the difference
between service trip and time profile. Such a path described by the used time profiles and
relative times is called a route.
Naturally, routes are suitable especially to aggregate display of recurring connections at
regular timetables. Two connections at different headway times which otherwise run the same,
are combined to the same route. This usually requires considerably less memory space.
When executing the timetable-based assignment with option Save paths as routes (see
User Manual, Chpt. 6.1.1.2, page 944), individual connections are still determined and loaded
internally. These are, however, only saved as aggregated routes after the assignment.
Reference is lost to the individual vehicle journeys as well as their exact departure times. The
PuT path leg list then shows the relative times for departure and arrival, and the optional
relations to the first and after the last vehicle journey item are empty. Because the network
elements are loaded prior to discarding the connections, time-based volumes can still be
determined.
The third option Save paths do not save (see User Manual, Chpt. 6.1.1.2, page 944) results
in that no path information is saved after ending the assignment. Only the derived values of the
network object volumes and also skim matrices are retained after the assignment. This way,
path-based post-assignment analyses are not possible especially no flow bundle calculation.
PuT path list and PuT path leg list also remain empty, however, time-based volume values are
also possible with this option.
Due to its differing user model, headway-based assignment (see "Headway-based
assignment" on page 430) not even internally determines connections but routes. The option
Save paths as connections can be selected, however, but at headway-based assignment
routes are saved in either case (or nothing). These are formally equal to those routes
determined by the timetable-based assignment and can be output in the same way as PuT
path list or PuT path leg list.
413 PTV AG
Chapter 6.3: PuT paths
Table 138 shows the path legs which result from a timetable-based assignment in example
Example.ver. In this case, the paths were saved as connections.
For the same assignment, Table 139 shows the path legs, when the paths were saved as
routes.
Origin
zone
Destinat
ion zone
Path
index
Path leg
index
Passen
ger trips
From
stop
point
To stop
point
Time profile ID Departure
100 200 1 25,000 10 40 06:10:00
1 10 OrigConn 06:10:00
2 10 20 BUS1 1_H > 1 06:10:00
3 20 20 Transfer 06:22:00
4 20 40 TRAIN 1_H > 1 06:25:00
5 40 DestConn 06:41:00
100 200 2 14.000 10 40 06:10:00
1 10 OrigConn 06:10:00
2 10 40 BUS1 1_H > 1 06:10:00
3 40 DestConn 06:55:00
100 200 3 18.000 10 40 06:55:00
1 10 OrigConn 06:55:00
2 10 40 BUS1 1_H > 1 06:55:00
3 40 DestConn 07:40:00
100 200 4 16.000 10 40 07:25:00
1 10 OrigConn 07:25:00
2 10 20 BUS1 1_H > 1 07:25:00
3 20 20 Transfer 07:37:00
4 20 40 TRAIN 1_H > 1 07:45:00
5 40 DestConn 08:01:00
100 200 5 17.000 10 40 07:25:00
1 10 OrigConn 07:25:00
2 10 40 BUS1 1_H > 1 07:25:00
3 40 DestConn 08:10:00
Table 138: Path legs after a timetable-based assignment (paths saved as connections)
Origin
zone
Destinat
ion zone
Path
index
Path leg
index
Passen
ger trips
From
stop
point
To stop
point
100 200 1 25,000 10 40 00:00:00
1 10 OrigConn 00:00:00
Table 139: Path legs after a timetable-based assignment (paths saved as routes)
414 PTV AG
6.4 PuT skims
By means of the Calculate PuT skim matrix procedure or during an assignment (see User
Manual, Chpt. 6.4, page 1004) the skim data can be calculated for the PuT skims of the various
skim categories (see "PuT skim categories" on page 414).
Since there are numerous routes or connections for an OD pair usually, the skims gained per
route or connection are aggregated to relation-based skim data by OD pair. Apart from the
service frequency which results from the number of connections, all skims are provided on the
level of connections as well as on the level of OD pairs.
6.4.1 PuT skim categories
The skims can be divided into six categories.
1. Skims of time (see "Skims of time" on page 415)
2. Skims of length (see "You can select the metric units meters or kilometers (alternatively:
imperial feet/miles) for skim matrices. Table 141 shows all skims of the length provided in
VISUM." on page 416)
3. Monetary skims (see "Monetary skims" on page 417)
4. Frequency skims (see "Skims of frequency" on page 417)
5. Skims of attribute data (see "Skims of attribute data" on page 418)
6. Derived skims (see "Derived skims" on page 418)
2 10 20 BUS1 1_H > 1 00:00:00
3 20 20 Transfer 00:12:00
4 20 40 TRAIN 1_H > 1 00:15:00
5 40 DestConn 00:31:00
100 200 2 49.000 10 40 00:00:00
1 10 OrigConn 00:00:00
2 10 40 BUS1 1_H > 1 00:00:00
3 40 DestConn 00:45:00
100 200 3 16.000 10 40 00:00:00
1 10 OrigConn 00:00:00
2 10 20 BUS1 1_H > 1 00:00:00
3 20 20 Transfer 00:12:00
4 20 40 TRAIN 1_H > 1 00:20:00
5 40 DestConn 00:36:00
Origin
zone
Destinat
ion zone
Path
index
Path leg
index
Passen
ger trips
From
stop
point
To stop
point
Table 139: Path legs after a timetable-based assignment (paths saved as routes)
415 PTV AG
Chapter 6.4: PuT skims
6.4.1.1 Skims of time
Skims of time (Table 140) are administered in seconds within the program VISUM. For skim
matrices you can select the unit minutes or seconds.
Skim Definition
Access time (ACT) Time required for covering the origin connector
Egress time (EGT) Time required for covering the destination connector
Origin wait time (OWT) Wait time at the start stop point (applies to the headway-based assignment
only, as for the timetable-based procedure OWT = 0 is assumed)
Note:
For the timetable-based procedure, an adapted origin wait time can be
calculated. (see "Adapted skims of time for the timetable-based assignment"
on page 416).
Weighted origin wait
time
Product from the origin wait time and the weighting factor of the origin wait time
in the settings for the impedance of the headway-based assignment. This skim
is only available in the headway-based assignment.
Transfer wait time
(TWT)
Wait time between arrival and departure at a transfer stop point
Note:
For the timetable-based procedure, additionally the adapted transfer wait time
can be calculated (see "Adapted skims of time for the timetable-based
Weighted transfer wait
time
Product from the transfer wait time and the weighting factor of the transfer wait
time in the settings for the impedance of the headway-based assignment. This
skim is only available in the headway-based assignment.
Extended transfer wait
time (XTWT)
Extended wait time according to the settings for the transfer wait time in the
perceived journey time definition for the timetable-based assignment.
In-vehicle time (IVT) Time spent inside PuT vehicles including dwell times at stops.
In-vehicle time by TSys
(IVTT)
Time spent inside PuT vehicles of a certain public transport system.
PuT-Aux time (XZ) Time spent in a vehicles of public transport systems of the PuT-Aux type.
Walk time (WKT) Walk time for transfer links between two stop points within a stop area or
between different stop areas of a stop
Journey time (JRT) Time between the departure from the origin zone and the arrival at the
destination zone
JRT = ACT + OWT + IVT + TWT + WKT + EGT
Note:
For the timetable-based procedure, additionally the adapted journey time can
be calculated (see "Adapted skims of time for the timetable-based assignment"
on page 416).
Table 140: Skims of time
416 PTV AG
Adapted skims of time for the timetable-based assignment
The skims OWT, TWT, JRT and RIT in the form described above always refer to the real origin
wait time and the real transfer wait time.
For the timetable-based assignment, also the adapted variants of these skims are available,
which contain the terms that are currently set up in the perceived journey time definition (PJT)
instead of the real origin and transfer wait times.
Unlike the real origin wait time which is constantly = 0 in the timetable-based procedure, the
adapted origin wait time can differ from 0 because it depends on the number of connections
provided in the assignment interval. The adapted transfer wait time depends on the user
settings for transfer wait time and can thus be limited. Furthermore, it can be transformed
implicitly by a polynomial for stronger weighting of extremely short wait times and for the
definition of a certain wait time (for example five minutes) as the optimum.
6.4.1.2 Skims of length
You can select the metric units meters or kilometers (alternatively: imperial feet/miles) for skim
matrices. Table 141 shows all skims of the length provided in VISUM.
Ride time (RIT) Time between the departure from the origin stop point and the arrival at the
destination stop point
RIT = IVT + TWT + WKT
Note:
For the timetable-based procedure, additionally the adapted journey time can
be calculated (see "Adapted skims of time for the timetable-based assignment"
on page 416).
Perceived Journey
Time (PJT)
Perceived journey time (see "Perceived journey time" on page 424)
PJT = f(ACT, EGT, OWT, TWT, NTR, IVT, WKT, XZ)
Adaptation time (ADT) Difference DeltaT between desired departure time and actual departure time
Extended adaptation
time (XADT)
User-defined adaptation time. Variant of the adaptation time which assumes
that the entire demand of each time interval is assigned to the connection with
the minimum impedance.
Skim Definition
Access distance (ACD) Length of the access route on the footpath from the origin zone to the
origin stop point
Egress distance (EGD) Length of egress route from destination stop point to destination zone
In-vehicle distance (IVD) Distance covered in vehicle without transfer walk links
In-vehicle distance per TSys
(IVTD)
Travel distance inside vehicles of a specific public transport system
PuT-Aux distance (AXD) In-vehicle distance for a PuT-Aux transport system
Walk distance (WKD) Length of a transfer link between the two stop points
Table 141: Skims of length
Skim Definition
Table 140: Skims of time
417 PTV AG
6.4.1.3 Monetary skims
Table 142 shows the monetary skims available in VISUM.
6.4.1.4 Skims of frequency
Table 143 shows the available frequency skims.
Journey distance (JRD) Distance covered between origin and destination zone
Journey distance = Access distance + In-vehicle distance + Walk
distance + Egress distance
Ride distance (RID) Covered distance from origin stop point to destination stop point
Ride distance = In-vehicle distance + Walk distance
Direct distance (DID) Direct distance between origin and destination zone
Skim Definition
Fare (FAR) Fare for the PuT ride between origin and destination zone (see "Fares" on
page 424)
Table 142: Monetary skims [Currency units]
Skim Definition
Number of transfers
(NTR)
Number of transfers between origin and destination stop point (per connection).
[-]
Service frequency
(SFQ)
For the timetable-based procedure, the service frequency is defined as the
number of different arrival times for connections departing within the
assignment time interval or in the succeeding extension period past the end of
the assignment time interval yet before a possible second occurrence of the
start of the assignment period. The latter especially means that the succeeding
period is not considered, if you do not use a calendar and define a 24-hour
assignment time interval covering the whole day.
For the headway-based assignment, a flow problem is solved on the graph of
all determined routes. Service frequency thus depends on the "weakest" part in
the transport supply.
Number of operator
changes (NOC)
Number of transfers with different operators of previous and next path leg. [-]
Number of fare zones Number of traversed fare zones. The skim depends of the ticket type(s) used
for the connection and returns zero if no zone-based ticket type is used. [-]
Table 143: Skims of frequency
Skim Definition
Table 141: Skims of length
418 PTV AG
6.4.1.5 Skims of attribute data
Table 144 lists the provided skim that results from the values of the selected attribute.
6.4.1.6 Derived skims
Derived skims (Table 145) result from a combination of the above listed skims.
Skim Definition
Path leg attribute (PLA) Throughout the entire path aggregated value of the selected (direct or indirect)
path leg attribute, for example Line route\AddValue1.
Table 144: Skims of attribute data
Skim Definition
Impedance in a time
interval (IPD)
Impedance of a connection = f (perceived journey time, fare, temporal utility).
For the skim matrix you can select whether the temporal component should flow
into the impedance in minutes or seconds.
Journey speed (JRS) Ratio of the journey distance and the journey time between origin and
destination zone [km/h]
Journey speed [km/h] = journey distance [m] / 1000) / journey time [min] /
60)
Direct distance speed
(DIS)
Ratio of the direct distance and the journey time between origin and destination
zone [km/h]
Direct distance speed [km/h] = direct distance [m] / 1000) / journey time
[min] / 60)
In-vehicle distance as
percentage by TSys
(IVTP)
Distance covered in the TSys as a percentage of the total in-vehicle distance of
the connection
Equivalent journey
time (EJT)
Skim value which results from a user-defined formula according to the set
parameters. The unit of the journey time equivalent is determined by the user-
defined formula.
Extended impedance
(XIMP)
The extended impedance is a component of the perceived journey time (PJT).
It can be defined in the settings for the impedance of the timetable-based
assignment and is thus only available in the timetable-based assignment.
Table 145: Derived skims
419 PTV AG
Utility (UTL) The Utility is based on the following:
On the one hand, the utility is based on C, which is the set of connections
determined for an OD pair.
On the other hand, the utility is based on the set of time intervals T = (t1, ...,
tn) resulting from the time series relevant to the OD pair or from refined time
series intervals, if applicable.
Per time interval t in T, each connection c in C has an impedance wt(c), which
depends on t, since the impedance may contain the time intervals distance
from the connections departure time.
Using an antitone utility function f, the respective utility ut(c) is calculated from
the impedance wt(c) according to ut(c) = f (wt(c)).
In case of the Logit model f(x) = e
-bx
.
The share of a connection c of the demand per interval t is then derived
according to the following formula.
The denominator U
t
is the overall utility of the time interval.
Compared to skims representing a mean value, U
t
improves with every new
connection that is added to the current transport supply.
For that reason the averaged U
t
calculated over all time intervals is accounted
for as a separate skim.
Here, d
t
is the total demand within time interval t.
Skim Definition
( )
( )
( )

=
C c
c
t
u
c
t
u
c
t
p
=
T t
t
d
T t
t
d
t
U
U
420 PTV AG
6.4.1.7 Examples for skims
illustration 146 and Table 146 illustrate a few skims for the connections of an OD pair.
Discomfort due to
capacity overload
(DISC)
Time during which a passenger has no seat in the course of this journey.
The skim is calculated as journey time weighted by service trip item. Its weight
is a function of the volume/seat capacity ratio.
For each individual PuT path C, the discomfort E(C) is defined as follows.
Here
a = Index over all service trip items of a PuT path C
F
a
= Journey time of the service trip item a (known from its time profile)
P
a
= Number of passengers on service trip item a (over all paths, determined by
assignment)
S
a
= Number of seats on service trip item a (based on the total of the seats of all
service trip sections which traverse the service trip item on the respective
calendar day)
A,B = free parameters
Path legs covered by PuT-Walk or PuT-Aux TSys in the PuT path are ignored.
Note
The discomfort due to capacity overload is only calculated with a timetable-
based assignment.
Connection 1 Connection 2
Used sequence of lines / route Bus1 Bus1, Train
Access distance [m] 300 300
Access time [min] 3 3
Table 146: Example of the connection skims of an OD pair
Skim Definition
( )

=
C a
B
S
P
A
e
a
F C E
a
a
Station
Bus 1
Train
A-Village
X-City
Bus 1
421 PTV AG
6.4.1.8 Availability of the skims in the PuT assignment procedures
Table 147 shows which skims can be calculated per PuT assignment procedure.
Run time [min] 45 28
Transfer wait time [min] 0 8
Egress distance [m] 500 500
Egress time [min] 5 5
Ride time [min] 45 36
Journey time [min] 53 44
Journey distance [m] 27.500 20,000
Direct distance [m] 18.385 18.385
Journey speed [km/h] 31.1 27.3
Direct distance speed [km/h] 20.8 25.1
Number of transfers [-] 0 1
Skim output by procedure Default ext. TSys-
based
HWay-
based
Timetable-
based
Journey time JRT X X X
Journey time adapted JRTA X
Ride time RIT X X X
Ride time adapted RITA X
In-vehicle time IVT X X X
PuT-Aux time AXT X X X
Origin wait time OWT X
Origin wait time adapted OWTA X
Weighted origin wait time WOWT X
Transfer wait time TWT X X
Transfer wait time adapted TWTA X
Weighted transfer wait time WTWT X
Extended transfer wait time XTWT X
Walk time WKT X X X
Access time ACT X X X
Egress time EGT X X X
Perceived journey time PJT X X
Number of transfers NTR X X X
Service frequency SFQ X X
Table 147: Availability of the skims in the PuT assignment procedures
Connection 1 Connection 2
Table 146: Example of the connection skims of an OD pair
422 PTV AG
6.4.1.9 Aggregation to mean skims per OD pair
Depending on the chosen search procedure there are different possibilities to aggregate the
skim values (Skim) of the connections to mean skim data (mSkim) by OD pair (Table 148):
Direct distance DID X X X
Journey distance JRD X X X
Ride distance RID X X X
Trip distance IVD X X X
PuTAux distance AXD X X X
Walk distance (transfer walk links) WKD X X X
Access distance ACD X X X
Egress distance EGD X X X
Journey speed JRS X X X
Direct distance speed DIS X X X
Fare FAR X X
Number of fare zones NFZ X X
Number of operator changes NOC X
In-vehicle distance per TSys IVTD X X X
In-vehicle distance percentage per TSys IVTP X X X
In-vehicle time per TSys IVTT X X X
Impedance IPD X X
Utility UTL X
Path leg attribute PLA X X
Adaptation time ADT X
Extended adaptation time XADT X
Extended impedance (XIMP) XIMP X
Equivalent journey time (user-defined) EJT X X X
Discomfort due to capacity overload (only
calculated during assignment)
DISC X
Aggregation functions HWay-
based
TT-
based
Unweighted quantile
For 0 z 1 the z-quantile of a finite, classified series of values (x
1
, ..., x
n
) is
defined as smallest number y, to which applies that # {i : x
i
y } / n z.
X X
Table 148: Combination of skim data to the mean skim value per OD pair
Skim output by procedure Default ext. TSys-
based
HWay-
based
Timetable-
based
Table 147: Availability of the skims in the PuT assignment procedures
423 PTV AG
The skim service frequency SFQ does not refer to a particular route or connection, but to an
OD pair.
For the timetable-based procedure, the service frequency results from the number of different
arrival times.
Example
For an OD pair, three connections are determined:
Weighted quantile
The connections are weighted with the volume at the calculation of the quantile.
X X
Unweighted mean X X
Weighted mean X X
Unweighted mean restricted to paths of sufficiently low impedance X X
Weighted mean restricted to paths of sufficiently low impedance X X
mSkim = skim value for route with minimum impedance X
mSkim = skim value for route/connection with minimum perceived journey time X
Connection 1 2 3
Volume 50 % 20 % 30 %
Number of transfers 1 3 2
Aggregation functions HWay-
based
TT-
based
Table 148: Combination of skim data to the mean skim value per OD pair
s Connection of Number
Conn Num
i
i
Skim
mSkim

=
=
1
=

=
Passengers
NumConn
i
i
Passengers
i
Skim
mSkim
1
j
j
j
j
Skim
mSkim
=
=

1
=

=
j
j
j
demand total of Share
j
j
j
Skim
j
demand total of Share
mSkim
1
1
424 PTV AG
By means of the different aggregation functions, the number of transfers by OD pair is
calculated as follows:
6.4.2 Perceived journey time
The perceived journey time PJT results from the weighted components of the journey time and
further components.
Perceived journey time PJT [min]
= In-vehicle time FacIVT (in)direct time profile item attribute 2)
+ PuTAux time FacAXT 1)
+ Access time
FacACT+ Egress time
FacEGT+ Transfer walk time FacTWT
+ Origin wait time FacOWT
+ Transfer wait time FacTWT
+ Number of transfers FacNT
+ Number of operator changes FacNOC 1)
+ Extended impedance FacXIMP 1)
1) timetable-based assignment only
2) headway-based assignment only, (in)direct vehicle journey item attribute in the
timetable-based assignment
The perceived journey time is used for the headway-based procedure and timetable-based
procedure, to evaluate individual connections during the connection choice. Weighting the
number of transfers strongly, for example, results in passengers preferring minimum transfer
connections.
In both procedures, boarding events and transfers can be evaluated in addition.
Headway-based assignment does not yet regard PuT-Aux times.
For the timetable-based assignment, the following options are provided:
the number of operator changes can be taken into account
the PuTAux time can be weighted with a TSys attribute
the extended impedance can be defined
Moreover, for each component a Lambda value can be entered and/or the option
BoxCox transformation can be activated.
6.4.3 Fares
VISUM can be used to calculate fares (see "PuT fare model" on page 546). The fare per
connection results from the used ticket type(s). It includes the specific supplement by transport
system (for ICE, for example). These fares are calculated for each connection and can be
regarded in the impedance definition of the timetable-based assignment. They can also be
Mean value 50 % quantile
unweighted weighted unweighted weighted
(1 + 3 + 2) / 3
= 2
1 0.5 + 3 0.2 +2 0.3
= 1.7
Values: (1, 2, 3)
50 % quantile = 2
Values: (1,1,1,1,1,2,2,2,3,3)
50 % quantile = 1
425 PTV AG
Chapter 6.5: PuT impedance functions
output as skim matrix and can be taken into consideration for the revenue calculation which is
performed by the PuT operating indicators procedure.
6.4.4 Temporal utility
For the timetable-based assignment, the temporal utility of a connection is included as a further
skim value in the definition of impedance (see "PuT impedance functions" on page 425).
The temporal utility of a connection depends on the following parameters:
Desired departure time, which is indicated by the temporal distribution of demand
Time difference T between provided time of departure and desired time of departure
Tolerance to differences between the provided time and the desired time of departure,
which is called the sensitivity to earlier or later departures
In this way it can be modeled that also the temporal position of a connection has an effect on
its attractiveness.
The temporal utility of a connection is highest for that interval in which the connection is placed,
because then T = 0 applies. The higher T, the lower the temporal utility.
In the timetable-based method, the temporal utility is included in the impedance definition in
different ways either by using a function N = f(DT) or by using T directly. In both cases, the
sensitivity towards early or late departure can be set by means of parameters.
For both variants, the following applies.
The shorter the period between the actual and the desired departure time, the higher the
temporal utility of the connection and the lower its impedance.
6.5 PuT impedance functions
Like PrT assignment procedures (see "Impedance and VD functions" on page 200) the PuT
assignment procedures derive the impedance of a connection (see "PuT skims" on
page 414)from several skims of this connection or route . Thus, the impedance is a user-
defined combination of various skims. According to requirements, a malus or a bonus can be
specified for various properties of a connection. The general rule is "The lower the impedance
of a connection, the higher its share of the transport demand".
In contrast to PrT, however, the impedance is used not only for the connection search, but also
to evaluate the connections during the connection choice by some of the PuT procedures.
Impedance can consist of times and fares. Due to the impedance dependency on the temporal
utility (see "Temporal utility" on page 425) at the connection choice of the timetable-based
Time series with hourly intervals
T (6-7) = 7:20 7:00 = 20 min
T (7-8) = 0 min
T (8-9) = 8.00 7.20 = 40 min
Table 149: Example for the determination of the time difference T
6:00 7:00 8:00 9:00
Dep. 7:20
426 PTV AG
procedure (see "Timetable-based assignment" on page 452), the impedance of a connection
can be different from time interval to time interval.
The actual definition of impedance differs in the various assignment procedures. The
timetable-based procedure actually uses different approaches in two of the calculation-internal
work steps. An overview is given in Table 150. All factors can be set freely and also be set to
zero, so that they are not considered in the assignment.
6.6 Distribution of the travel demand to PuT connectors
Similar to the PrT origin and destination demand also the PuT origin and destination demand
can be distributed arbitrarily or by percentage (see "Distribution of demand of a zone to the
connectors" on page 35). Hereby, a distribution by percentage does not distinguish between
two variants of distribution; rather the overall demand is distributed. The distribution by
percentage may be used, for example, to assign transport demand to all stops situated within
a community (modeled as zone).
The proportional distribution of the PuT is effected similar to the distribution by percentage of
PrT. All origin and destination demand of the zone is distributed onto all connectors of the zone
proportionally to their respective current connector weights. For each connected node a
temporary virtual zone is created whose overall demand receives the share of overall demand
that was originally defined for this connector of the original zone. The assignment is calculated
on the basis of the virtual zones. After terminating the assignment, the temporary zones are
deleted again and the results are allocated to the original zone.
Example
Two zones with the following connectors are given.
Zone 100 with distribution by percentage, connected nodes 1, 2 and 3
Zone 200 with distribution by percentage, connected nodes 4 and 5
The connector weights for origin and destination are set according to Table 151.
Procedure Definition of impedance
Timetable-based
Branch&Bound
Search
IMP = JRT Fac1 + NTR Fac2 + TSysIMP Fac3
Timetable-based
Shortest path
search
IMP = JRT
Timetable-based
Choice
IMP = PJT Fac1 + Fare Fac2 + Tearly Fac3 + Tlate Fac4
Headway-based
Search
IMP = IVT + TWT Fac1 + NTR Fac2
Here, TWT represents the expected wait time for the line the passenger wants to
board for the transfer.
Headway-based
Choice
IMP = PJT Fac1 + Number of fare points Fac2
Table 150: Comparison of the impedance functions in the PuT assignments
427 PTV AG
Chapter 6.7: Allocation of skims with reference to lines/links
Transport demand from zone 100 to zone 200 = 1000 trips
Transport demand from zone 200 to zone 100 = 500 trips
For the assignment, this leads to the temporary demand matrix displayed in Table 152.
The value of the temporary OD pair 1 4 is calculated from 1,000 0.2 0.9 = 180.
6.7 Allocation of skims with reference to lines/links
Certain attributes, for example the line network length of a transport system or the attributes
number of service trips or PuT volume of a link are in an intermediate position, because
spatially their definition refers to a link and also to a line route. Since stop points may optionally
be placed on links, and both line routes and service trips extend from stop point to stop point,
only certain sections of links may be traversed by line routes or service trips.
In most cases, proportional allocation of these skim values to the link does not make sense,
which is why the definition for those skims has been standardized:
A link is regarded as being used (completely) by an object of the line hierarchy if the link section
traveled accounts for at least half of the link length ( 0.5). For skim values that refer to sections
between stop points (for example volume), the following applies. To each stop point on a link
the nearest node is allocated (either the FromNode or ToNode of the link). The skim value of
the section between the last stop point, to which the FromNode is assigned, and the first stop
point, to which the ToNode is assigned, is regarded as the skim value for the (entire) link.
illustration 147 shows a skim value calculation example for such partially traversed links.
Connector node Weight (origin) Weight (destination)
1 20 0
2 30 80
3 50 20
4 40 90
5 60 10
Table 151: Connector weights for the example
Virtual zone 1 2 3 4 5
1 - - - 180 20
2 - - - 270 30
3 - - - 450 50
4 0 160 40 - -
5 0 240 60 - -
Table 152: Temporary demand matrix for the assignment in the example
428 PTV AG
Illustration 147: Example for skim value calculation for partially traversed links
Line route 1 touches the links 2, 3, and 4 (because the section traveled accounts for at least
half of the link), not link 1 however, because the traversed section is < 0.5 on link 1. Vehicle
journey 1 only touches link 3. The volume between the stop points B and C is regarded as the
PuT volume of link 2, while for link 3, volume C D applies and for link 4, the volume between
D and E.
6.8 Transport system-based assignment
The transport system-based assignment does not differentiate between individual PuT lines.
Modeling the transport supply only considers the links of a basic network with their specific run
times. The basic network can comprehend the following sets of links.
All road and rail links of the link network
Only those links which are traversed by PuT lines
Only those links which are traversed by active PuT lines
From the links of this basic network a graph is constructed which is the basis for a best-route
search.
Because individual lines are not distinguished, transfer stops with their respective transfer
times cannot be included in the search. It is possible, however, to include transition times
between different transport systems (transfer penalties for transport system changes, for
example between bus and train).
The transport system-based assignment calculates exactly one route for each pair of origin
zone and destination zone, which consists of one origin connector and one destination
connector for the PuT as well as of links and turns, which are permitted for a public transport
system. Transfers are changes of the transport system which are considered in the form of a
time penalty in the route search.
For links, t-PuTSys is considered
A transport system change can only take place at selected nodes
At nodes, where a transport system change is necessary, a transfer time penalty TP is
assigned
TP = node type-specific time penalty + penalty per transfer
At nodes, at which no turn for the public transport system is permitted between the links,
the time penalty TP is also added if option Consider prohibited turns is active.
Node Stop point
Links
Line route 1
Service trip 1
1 2 3 4
A B C D E
429 PTV AG
Chapter 6.8: Transport system-based assignment
6.8.1 Evaluation of the transport system-based assignment
The transport system-based assignment is characterized by the following features.
The timetable (service frequency, transfer wait times) is not considered.
Unrealistic route choice caused by frequent transfers within a transport system.
Lines of the same transport system which run in parallel but have different PuT run times
(for example bus 1 and bus 2) can only be represented by a mean PuT run time.
The journey time or ride time can be estimated if PuT lines have short headways.
Number of transfers, transfer wait time, and service frequency cannot be calculated.
The assignment procedure based on transport systems is recommended for a first draft of a
new line network. The procedure calculates the shortest routes (minimum time required) which
are then charged with the travel demand. The resulting volume flows represent the "desired
line network" of the passengers.
The volumes resulting from the timetable-based assignment and the headway-based
assignment will differ significantly from the results calculated by the transport system-based
assignment. Under no circumstances neither a timetable-based nor a headway-based
calculation should be replaced by the transport system-based procedure.
6.8.2 Example for the transport system-based assignment
For the PuT supply in the example (see "Example network for the PuT assignment procedures"
on page 409), the procedure determines the following shortest route given a transfer penalty of
10 minutes for the transfer from bus to train.
12 minutes from A-Village to Station with transport system Bus
16 minutes from Station to X-City with transport system Train
With a 10-minute transfer penalty, this results in a ride time of 38 minutes. All 90 trips from A-
Village to X-City are assigned onto this route.
This results in the volumes shown in illustration 148.
Illustration 148: Network volume after transport system-based assignment (parameters file TSys1.par)
90
90
0 0
Station X-City
A-Village
B-Village
430 PTV AG
From a transfer time of 18 minutes onward, the TSys bus is used instead of the train for the
section between the Station and X-City (illustration 149).
Illustration 149: Network volume after transport system-based assignment (parameters file TSys2.par)
6.8.3 Steps of the transport system-based assignment
On the links, connectors and turns which are permissible for public transport systems in the
network, the transport system-based assignment determines the routes with the minimum
impedance for each OD pair.
6.8.3.1 Route search
The impedance of a route consists of the following components.
Run times of traversed links
Transfer penalty for every transport system transfer
Node type-specific or stop-specific transfer penalties
For links which may be used by several public transport systems with different run times, the
minimum run time is used.
6.8.3.2 Route loading
The total demand of an OD pair is assigned to the route with the lowest impedance.
The transport system-based procedure carries out exactly one best-path search for every OD
pair.
6.9 Headway-based assignment
For the headway-based procedure, each line is described by the line route, the run times
between line stops, and the headway. Actually, it is the time profile which comprises this
information and the headway-based procedure works on this model level (see "Network
90
0
90 90
Train X-City
A-Village
B-Village
431 PTV AG
Chapter 6.9: Headway-based assignment
objects of the line hierarchy" on page 46). In the following sections the term line is used for the
sake of convenience. This emphasizes that the timetable of the individual service trips is not
regarded.
Transfer wait times are usually regarded globally, which means that the departures of different
lines are independent of each other. As a standard, a timetable coordination is not taken into
consideration. By explicit modeling, however, it can be expressed that lines operate with the
same headway each on a shared section, or rather a fixed transfer wait time exists between
two lines (see "Matched transfers" on page 450). TSys of the PuT-Aux type are not yet
regarded.
The headway-based assignment procedure includes the three operational steps.
1. Headway calculation (see "Headway calculation" on page 432)
2. Route search and route choice (see "Route search" on page 446 and "Route Choice" on
page 447)
3. Route loading
In the combination of search and choice, the headway-based procedure differs from the
timetable-based assignment. In this second step, possible paths between two traffic zones are
detected and simultaneously a distribution is specified between them. The paths do not
represent connections, but routes (see "PuT paths" on page 412), as the calculation is not
done on the time axis, but merely regards travel times and headways. In the third step, the
routes found in the search are loaded with the demand from the demand matrix and stored in
memory (if desired).
6.9.1 Evaluation of the headway-based assignment
The headway-based procedure is characterized by the following features.
The procedure, as is the case with the timetable-based assignment, not only determines
the optimum routes, but also those that are good enough. However, the transfer wait time
goes in only globally here.
A co-ordination of the timetable is regarded only if the co-ordination has been modeled
explicitly (see "Coordination" on page 449).
The number of transfers, journey time and the ride time can be estimated with sufficient
accuracy if all lines have short headways.
The bandwidth of various choice models offers the big advantage of being able to configure
the procedure in such a way, that it precisely reflects the available passenger information
provided in the analyzed network. Accordingly, you can apply different models to make an
estimate of the benefit, which can be achieved by investing in passenger information
systems.
Compared to the timetable-based procedure, the headway-based procedure shows a
considerable reduction of computing time for most PuT networks, this is especially the case
for networks with regular headways (fixed-time rhythm). In networks in which many lines
consist of only one trip, however, time savings are low.
Because the headway-based procedure normally does not take the co-ordination of the
timetable into account, the procedure is suited for public transport planning in urban areas,
particularly if the current state (exact timetable is available) is to be compared with
scenarios for which no exact timetables exist yet. This procedure is not suited for PuT
432 PTV AG
supply planning in rural areas or for long-distance transport, because in these cases long
headways occur, and it is an elementary planning task to provide connections.
The headway-based procedure cannot regard the fares for the impedance calculation. For
a fare model-based impedance calculation, use the timetable-based procedure instead
(see "Calculation of the fare revenues (revenue calculation)" on page 594).
6.9.2 Headway calculation
You can define the headway of a line in three different ways (see User Manual, Chpt. 6.2.3.1,
page 956).
from a (usually user-defined) time profile attribute
from the mean headway according to the timetable
from the mean wait time according to the timetable (default setting)
Each of the three methods can be applied separately by time interval. That way you can model
that the transport supply varies within the assignment period for example, because of the
higher demand during morning peak hours.
From time profile attribute
In the simplest case, directly enter the headway as an attribute of the respective time profile.
The specification of a timetable is then dispensable. An existing timetable is ignored.
From mean headway according to timetable
VISUM can also automatically calculate the headway from the timetable of the time profile. For
that purpose, the number of departures n is determined for each time interval l = [a,b) within the
assignment time interval. The headway results as the quotient.
In the case of networks with short headways and sufficiently broad time intervals, this simplified
approximation is acceptable. Generally speaking, however, this approach is problematic for
two reasons.
On the one hand, the definition is too susceptible to shifts of individual departures beyond
interval limits, which leads to inconsistencies in the result. This problem always occurs when
the actual headway of a line is not a divisor of the length of the demand time interval. For a line
with a 40-minute headway, for example, and the time interval l = [6:00,7:00), different
headways are calculated for the particular departure times (Table 153).
On the other hand, this approach cannot reflect the following fact: For the passenger who
arrives at random, trips spread evenly throughout the time interval generally mean less wait
time than trips that are piled up. The following third definition, therefore, is used as the default
setting for the headway-based procedure.
Departure times Trips in the time interval Calculated headway
5:55, 6:35, 7:15, ... 1 60 minutes
6:05, 6:45, 7:25, ... 2 30 minutes
Table 153: Example for headway calculation from mean headway according to timetable
a b , b a
n
------------ =
433 PTV AG
From mean wait time according to timetable
The headway
a,b
of a line is defined as double the expected wait time for the next
departure of the line in the case of random access in the time interval [a,b).
F
l
= {x
1
, x
2
, ..., x
n
} is the set of departure times of the line in interval l = [a,b).
The first departure after time b is indicated as x. Since such a departure does not have to exist
or can occur later, the fictitious departure x = x
1
+ (b-a), which results from the cyclical
continuation of the timetable in l, is also considered. For the calculation of the wait time at the
end of l the departure x
n+1
= min{x,x} is used.
The headway is then defined as follows.
Here applies: , and to the
remaining i {1, ..., n-1}.
i
is in each case the expected wait time in a sub-interval.
If you now look again at the example with the 40-minute headway and the interval l = [06:00
AM,07:00 AM), you get a much more balanced picture.
Using the example in the first row, the calculation can be briefly explained as follows.
In this case n = 1, x
1
= 06:35 AM and x
2
= 07:15 AM apply.
Therefore follows
and
Overall this results in minutes.
Compared to the case of the naive approach , this example shows that the calculated
values vary far less when shifting the specific departure times.
6.9.3 Generalized costs as impedance
For route search and choice (see "Route search" on page 446 and "Route Choice" on
page 447), paths are assessed by their impedance or generalized costs (see "PuT
impedance functions" on page 425) respectively. This term contains the perceived journey
time, PJT, and a number of fare points.
IMP = PJT FacPJT + NumberFarePoints FacNumFP
The perceived journey time, PJT, has the unit "Minutes" and consists of the following times.
PJT [min] = in-vehicle time FacIVT weight attribute of the time profile item
Departure times Trips in the time interval Calculated headway
5:55, 6:35, 7:15 1 43 20
6:05, 6:45, 7:25, ... 2 33 20
Table 154: Example for headway calculation from mean wait time according to timetable
a b , 1
b a
------------
i
i 0 =
n
0
x
1
a ( )
2
=
n
x
n 1 +
x
n
( )
2
x
n 1 +
b ( )
2
=
i
x
i 1 +
x
i
( )
2
=
0
6:35 6:00 ( )
2
1225 = =
1
7:15 6:35 ( )
2
7:15 7:00 ( )
2
1600 225 1375 = = =
6:00 7:00 , 2600

60
------------ 43,3 = =
a b ,
434 PTV AG
+ PuT-Aux time FacAXT 1)
+ Access time FacACT
+ Egress time FacEGT
+ Transfer walk time FacTWT
+ Number of transfers FacNT
Here, journey times, costs, etc. are deterministic. The origin wait time and the transfer wait time
result from the previously specified headway of the PuT line which the passenger boards at the
origin stop or at the transfer stop. Within the limits of their headways, they depend - except in
the case of co-ordination (see "Coordination" on page 449) - in a random way on the transfer
lines' relative position to each other. PuT-Aux transport systems are not yet taken into
consideration.
The run time can be multiplied by a user-selected time profile item attribute in order to model
the vol/cap ratio (for example the availability of seats) or other aspects of usability (for example
the level of comfort) of a line.
Other individual time penalties and weighting factors for boarding events or transfers can be
taken into consideration as follows (see User Manual, Chpt. 6.2.3.4, page 962).
A boarding penalty from any time profile attribute
A mean delay from any time profile item attribute
A wait time factor from any stop area attribute
With the time penalties you can for example model, that some lines are favored by the
passengers because of their better quality of traveling, or because they are usually punctual.
Via the wait time factors you can model that the passengers prefer waiting at some stops than
others.
6.9.4 Choice models for boarding decisions
In the headway-based assignment it is usually assumed that passengers know line headways
and times.
Which additional information they have, is decisive for their choice behavior when boarding or
transferring. VISUM offers four different models.
No information and exponentially distributed headways
No information and constant headways
Information on the elapsed wait time
Information on the next departure times of the lines from the stop
The latter applies for example, when dynamic passenger information systems have been
installed at stops. The passengers can then see which of the departing lines in the current
situation offer the least remaining travel time to their destination. As a result, they will for
example not board a line if the information system gives them the information, that shortly after
this line there will be another much faster line.
The individual choice models for the situation of a passenger waiting at a stop are introduced
below. To describe the mathematical basis, we still require a few terms.
435 PTV AG
Notation
L = {1, ..., n} specifies the set of available lines. Each line i L has a certain remaining journey
time s
i
0 an a headway h
i
> 0. The frequency of the line is derived from the headway.
The term "remaining" should make it clear that we are talking about the remaining journey time
from the currently considered stop to the destination zone. Only for the choice situation at the
origin zone we are talking about the journey time of the entire path.
For the purpose of a more simple modeling we assume additionally that the lines are sorted in
ascending order according to their remaining journey time. Thus the following applies s
1
s
2

... s
n
. The set of the first i lines is abbreviated as follows: L
i
= {1, ..., i}.
Note, that the remaining journey time s
i
in fact stands for the generalized costs of line i, which
contain transfer penalties and further impedance components. For a better understanding we
will still be talking about "Times".
On the basis of the available information the different choice models calculate the optimal set
L
*
L and for each line i L
*
a demand share
i
0.
It is clear that a line i must be part of L
*
, if another line j is contained in L
*
and if for the
remaining journey times s
i
< s
j
applies. From sorting the times it can be deducted that i
*
exists,
as a consequende L
*
= L
i*
.
The wait time which applies when choosing any set L before boarding, is designated as W
L
.
The respective remaining costs are given as follows.
The parameters are random variables because they depend on the random arrival of lines at
the stop.
For the optimal set L
*
also the following applies: E(C
L*
) E(C
L
) for any L

L.
6.9.4.1 No information and exponentially distributed headways
If the passenger does not have additional information, he has to decide ad hoc whether to
board the arriving line or not. The choice model determines the optimal set of lines, and the
optimal strategy of the passenger is to choose the line in the set that arrives first.
In addition to the missing passenger information, the model introduced in this section is most
notably characterized by the fact, that the headway (the temporal gap between two departures
of a line) is not assumed to be a constant, but rather exponentially distributed. The expected
gap value is exactly the same as for constant headways 1 /
i
, therefore the "Frequency" of the
line. In contrast to constant headways, however, the headway times strongly scatter around
this value.
Fundamental characteristic of the exponential distribution which is taken as a basis is that the
wait time which has already elapsed since the last departure of the line, does not state how
long the passengers have to wait for the next departure. This property is called
"Memorylessness". Thus, the greatest possible irregularity of the timetable is assumed.
i
1
h
i
---- =
C
L'
W
L'

i
s
i
i L'
+ =
436 PTV AG
The optimal set under these model assumptions is composed as follows. The following is set
first:
Then, the optimal line set is achieved by L
*
= L
i*
, where i* = max{i:s
i
u
i-1
}.
It can be proved that the i
*
composed in such a way reduces the expected remaining costs.
A line i thus exactly belongs to the optimal set, if its remaining travel time (without wait time) is
not higher than the expected remaining travel time plus wait time of the combined lines L
i-1
=
{1, ..., i-1}. This procedure has the effect, that comparatively few lines are used, because with
this comparison the lines L
i-1
are treated in such a way, as if they were perfectly coordinated.
Coordinated here means, that they are arranged so evenly, that they appear as a single line
with frequency . Such an additivity is only given in the case of exponential
distribution.
The share of the lines i L
*
are equal to the probability, that they depart first, as can be taken
from the following formula.
Note, that the remaining travel times of the lines do not appear in the share definition. If lines
are adequate enough to be contained in the optimal line set, their shares only depend on their
headways. This property illustrates the heavily simplified construction of this choice model.
The resulting expected wait time is as follows.
This choice model should only be used, if the line headways are extremely irregular, in other
words, if the passengers face a high level of uncertainty.
6.9.4.2 No information and constant headways
With the same level of information, however, constant headways, the strategy of a passenger
is in principle the same. From an optimal line set L
*
= L
i*
he or she selects the line which
arrives first. The determination of i
*
now follows the following different approach.
You can recalculate that it is insufficient in this case, to regard the result (L
1
, L
2
, ..., L
n
) of
potentially optimal line sets and to cancel exactly at that point when for the first time the
u
i
1
j
s
j
j 1 =
i
j
j 1 =
i
---------------------------------- =

j
j 1 =
i 1
i

i
j
j L
----------------------- =
E W
L
( )
1
j
j L
----------------------- =
437 PTV AG
following applies: EC
Li
> EC
Li-1
. This is caused by the fact, that there can be more than one
local minimum in the sequence (L
i
). Therefore guarantees, that the
optimal line set is composed exactly from those lines, which reduce the expected remaining
costs if being included in the selection.
The shares assigned to the individual lines again correspond with the possibility of arriving first.
is the minimal occurring headway. This results in the following expected wait
time.
If the timetable in the analyzed network is regular and only slightly irregular, and the
passengers do not have any information on departure times, this choice model is more realistic
than the model considered before.
6.9.4.3 Information on the die elapsed wait time
If - in case of constant headways - the passenger makes use of the information on how long he
has been waiting already at the stop, he will be able to reduce his expected remaining costs -
in contrast to the previously described models. The passenger knows for example, that after
waiting eight minutes, a line with 10 minutes headway has to arrive within the next two minutes.
The passenger can make use of this information and ignore potentially earlier arriving lines,
which are, however, at least two minutes slower.
The passenger has this information independently of the external infrastructure. To assume
this is therefore not a strong assumption.
In this case, the optimal line set L
*
depends on the elapsed wait time and is therefore no longer
constant. Determining the set is more difficult than in the previous cases. It can be proven that
L
*
has the following shape.
Given are i
*
n and an orderly sequence of times 0 t
i*
...

t
l
. This means that the in time
interval I
j
= (t
j+1
,t
j
] just L
j
= {1, ..., j} forms the optimal line set. t
j
is here the exact point in time
t, from which onward the remaining journey time of line j the expected remaining costs
(including wait time according to t) of the lines L
j-1
. In other words, t
j
is the unique solution for t
in .
The optimal strategy is as follows. If the passenger observes an arrival of a line from I
j
, after
wait time L
j
, he will board that line. Other lines he will ignore.
One can show that this strategy reduces the expected remaining costs. As illustrated in the
following, it corresponds more with the real behavior of passengers than its abstract definition.
i
argmin
i
EC
L
i
{ } =
i

i
1
j
w ( )
j L
j i ,
w d
0
h
=
h min h
i
{ } =
E W
L
( ) 1 w
j
( )
j 1 =
i
w d
0
h
=
s
j
E C
L
j 1
W t > ( ) t =
438 PTV AG
Because the passenger knows the headways of all lines, his knowledge on which available
lines are still worth taking, increases the longer he is waiting. Comparable slower lines may still
be reasonable options at the beginning of the wait time. There is a time, however, when the
evaluation topples. At a certain time, the expectancy for the remaining wait time for the faster
j-1 lines is less than the difference between their remaining travel time and the remaining travel
time of the line j. Exactly as of this time is it no longer worth it to take line j even if it arrives
immediately. The times t
j
mentioned above are exactly those moments where a line j is no
longer included in the optimal line set L
*
.
Example
Let us regard the following simple situation of two lines.
The passenger waits maximum 15 minutes to continue his journey. After t minutes the
expected remaining travel time for line 1 is exactly 10 + (15 - t) / 2 minutes. To determine the
point of time as of which this expected value is less than the run time of line 2, you resolve 10
+ (15 - t) / 2 13 according to t which results in t 9, thus t
2
= 9.
In other words, a vehicle of line 2 can be ignored after 9 minutes, because the three minutes
longer run time of line 2 is not made up by the mean remaining wait time for line 1.
6.9.4.4 Information on departure times
This model is based on the assumption that a passenger does not only know the times and
headways of all lines, but can (at least at the stop) also get information on precise departure
times. The optimal strategy can thus be formulated as follows.
A passenger boards the line that offers the least remaining costs given the actual
departure times.
Unlike in previous cases, the passenger does not simply board the first arriving line of a certain
(possibly time dependent) set. Because all wait times w
i
are known, the passenger's decision
is not subject to stochastic influences. He or she rather selects exactly that line whose
remaining costs s
i
+ w
i
are at a minimum.
The optimal line set thus consists of all lines, which have the least costs in some timetable
positions.
and
The optimal set of lines are those, which are optimal in border cases, since they arrive without
a wait time, whereas all other lines have to be waited for by a complete headway.
The calculation of shares is as follows.
(59.1)
Line Run time Headway
1 10 15
2 13 15
Table 155: Considering elapsed wait time
i
max i: s
i
min
j
s
j
h
j
+ { } < { } = L
L
i
i
= P C
i
C
j
< j ( )
439 PTV AG
(59.2)
(59.3)
(59.4)
(59.5)
(59.6)
Explanation of the derivation
In row (59.1), the entire passenger information is used. Line i is selected if its remaining costs
C
i
are lower than those of the other lines. Row (59.2) reformulates the expression, by using the
density function of the random variable C
i
. Due to constant headways C
i
is equally distributed
in [s
i
,s
i
+ h
i
). (If the wait time is weighted with a factor, this should be put in front of h
i
, the
calculation otherwise does not change.)
In row (59.3) we take advantage, that the departures of the lines are independent of each
other. In all choice models this is a basic assumption of the headway-based assignment. To
avoid case differences, the integration range in(59.5) is separated into sections, in which the
inner product is extended over a constant set of lines. It has to be noted that for j > k and x
[s
k
,s
k+1
) the following must apply: P(C
j
> x) = 1. This is due to the sorting of the lines at the
beginning, because the costs of line j > k sum up to at least s
k+1
. In the last step we then apply
the distribution function of C
j
which (59.6)again is an equal distribution. At the end of the
invoice, the result is a sum of polynomials with a maximum degree of i
*
.
The expected wait time is achieved analogously.
=
1
h
i
---- P C
i
C
j
< j C
i
x = ( ) x d
s
i
s
i
h
i
+
=
1
h
i
---- P
j i
C
i
C
j
C
i
x = < ( ) x d
s
i
s
i
h
i
+
=
1
h
i
---- P
j i
C
j
x > ( ) x d
s
i
s
i
h
i
+
=
1
h
i
---- P C
j
x > ( )
j 1 =
j i
k
x d
s
k
s
k 1 +
k i =
i
=
1
h
i
---- 1
x s
j
h
j
------------

j 1 =
j i
k
x d
s
k
s
k 1 +
k i =
i
440 PTV AG
To assume passenger information is no extremely strict requirement. Many places already
have information systems which display the next departure times on the basis of real-time
operating data. Alternatively, timetables could be hung up at stops. There are also no limits
regarding other technical resources.
6.9.5 The complete choice model
The choice model for boarding decisions all apply to the situation of a passenger, who is
waiting at a stop for departures of suitable lines (see "Choice models for boarding
decisions" on page 434). Even if the assumed level of information varies strongly between the
models, it always applies that the passenger decides for one of the different lines, due to
observations (arriving vehicles).
In general, there may also be other situations:
The passenger is still at the start of the journey (at origin zone).
The passenger is on board a line.
The passenger can choose between transfer stops which may only be reached by a
footpath.
In such cases, the choice has to be modeled in a different way, because it generally is not
based on observations, but on estimates. However, when passengers rely on estimates or not
again depends on the passenger information available in the network. Below it is described
briefly under which conditions observations are not restricted to the departures of the lines at
the current boarding stop.
6.9.5.1 Extended applicability of the departure time model
With a suitable infrastructure, a stop-based departure display can also be seen by passengers
in arriving lines before alighting. In this case, the choice model Information on departure
times (see "Information on departure times" on page 438) is not just applied to the possible
transfer lines, which are available after alighting. In fact, it already refers to the decision of the
passenger still on board, because by acknowledging the departure times early enough, the
passenger can judge whether continuing the journey on the same line is more profitable than
getting off. This also applies, if information on connections provided at the next stop is
displayed in the vehicles.
Another relevant difference in cases is the question, whether passenger information systems
at a stop only display departure times of those lines which depart from just this stop. In some
places, displays are used which also include the departures of other lines, departing at stops
close-by. An example of this is the display of departures of subway lines in the concourse.
Are both of these features provided, also a passenger who is still on board of a line knows the
next departure times of all potential transfer lines at the current stop and at those which can be
reached by foot from this stop. The model is then applied to the total set of available lines. The
technical realization of such a level of information can for example be a service, which provides
E W
L
( )
1
h
i
---- x s
i
( ) 1
x s
j
h
j
------------

j 1 =
j i
k
x d
s
k
s
k 1 +
k i =
i
i 1 =
i
=
441 PTV AG
via cell phone the information on the current timetable and - on the basis of operational real-
time data - a recommendation for the passenger. A completely different model assumption,
which nevertheless leads to the same level of information, is the passenger's knowledge of the
timetable.
The border case of complete passenger information is provided, if the situation described
above is also assumed, when the passenger is still at the starting point (thus in the origin zone)
of his journey. In order to observe also the departure times of the possible boarding lines from
there, again a mobile information service or complete knowledge of the timetable have to be
assumed.
6.9.5.2 Modeling the choice on the basis of estimates
Apart from the case of complete passenger information, there always are also decisions which
are made on the basis of estimates. The simplest example is the choice between several
boarding stops at the start of the journey or at a transfer. If passengers do not have any
information on departure times on board, the decision on continuing the journey or getting off,
in this case depends on the expected remaining journey time after alighting.
Such decisions can be modeled in two ways:
By a discrete choice model
By a 0/1 decision in favor of the best alternative
The second case reduces the expected remaining costs, however, does not reflect the
fuzziness of the passengers' behavior. That is why a discrete choice model should be favored
normally. If the flexibility parameter goes towards infinity, the result comes close to the 0/1
decision in favor of the alternative with the lowest expected remaining costs anyway.
6.9.5.3 Hierarchical structure of the choice
In general, we can now model a passenger's decision as a sequence of separate decisions.
Each of them is either based on estimates or observations. In the first case, we use a discrete
choice model to obtain a distribution between the alternatives. In the second case, one of the
choice models for boarding decisions is applied (see "Choice models for boarding decisions"
on page 434).
The result of the decision made on a lower level becomes part of the decision on a higher level,
in form of expected remaining travel time.
The different levels of information and the various decision situations produce different
hierarchical structures for the passenger's decision as a whole. Three examples illustrate the
procedure in principle (see "Example for the choice models" on page 441).
6.9.5.4 Example for the choice models
Let us look at the following network.
442 PTV AG
Illustration 150: Example network for choice models
We analyze the decision of a passenger, who is on board of line 1 and arrives at stop A. First,
we will look at how the structure of the choice made changes, if the available information
varies.
The analyzed scenarios are the following.
1. No information, constant headways
2. Departure time information per stop, not available on board.
3. Departure time information per stop, also available on board.
4. Departure time information for all stops, not available on board.
5. Departure time information for all stops, also available on board.
Hierarchical structure
In the first example we are looking at the situation in scenario 1.
Illustration 151: Structure of the choice in scenario 1 (no information)
In the illustration, circles represent lines and rectangles indicate stops.
A
B
C
Destination
Line 1
Line 2
Line 1
Line 3
Origin
Line 4
Line 5
+2 walk time
+1 walk time
4 5 4 5 4 5 4 5 4 3
1
2
?
Alight
A B C
443 PTV AG
Here the passenger first decides between continuing the journey or getting off, though the
remaining journey time resulting from the second alternative can only be estimated. After
alighting a decision is made for the boarding stop (A, B or C), which again is only based on
expected values. Only after having arrived at this stop the passenger can make a definite
decision on the boarding line, on the basis of observations (of the arriving vehicles).
In the second example we assume that departure times are displayed at stops. The decision
structure then changes as follows.
Illustration 152: Structure of the choice in scenario 2 (local information)
In contrast to the example above, the passenger identifies the next departure times of line 2
directly after getting off at stop A. The passenger is thus able to determine exactly what the wait
time and the remaining journey time will be, if he continues his journey from there. Compared
to that, the passenger knows only expectations for the boarding stops B and C.
In the third example, let us assume that already on board the line the passenger can find out
which connections are available from stop A. The decision tree then looks as follows.
4 5 4 5 4 5 4 6 5 4
1
2
?
Alight
B C
Change
444 PTV AG
Illustration 153: Structure of the choice in scenario 3 (information in the vehicle)
The characteristic of the first decision now changes, because continuing the journey with line
1 and a transfer to line 2 or 3 now represent alternatives on the same level, as all wait times
are known.
Comparison of the calculated shares
It is informative to know what influence the applied choice model has on the shares of the lines
and the mean remaining costs. Let us take the following definition of generalized costs to
simplify the calculation.
Costs = 1.0 In-vehicle time + 1.0 Walk time + 1.0 Wait time + 1 min Number of transfers
Travel times and headways of the lines in the example network are illustrated in Table 156.
The passenger's situation on board line 1 arriving at stop A is interesting, because there are
several transfer options which assure a shorter remaining journey time. Table 157 shows, that
the passenger can derive a much bigger advantage from these transfer alternatives, the more
information he has on the arising wait times.
Line Run time Headway
1 Start -> A 5
A -> Destination 8
10
2 3 15
3 5 5
4 4 5
5 3 10
Table 156: Travel times and headways of the lines in the example network
4 5 4 5 4 5 4 6 5 4
1 2
?
Alight
B C
445 PTV AG
The mean costs in the last row refer to the entire route.
The difference between scenario 1 and 2 is very small, because information on departures at
the local stop is only an advantage if thereby one is able to ignore a line with a longer journey
time in favor of a more appropriate line arriving shortly after. In this network, this case only
occurs with a low probability and only at stop B.
If the same information is already provided on board (scenario 3), the shares of the individual
lines already change considerably, the mean costs, however, only a little. The reason being,
that the most attractive transfer lines in this example do not depart from stop A.
Because of this, the expected remaining costs are then reduced when information on
departure times are not only provided for the local lines of a stop, but for all the lines of all stops
nearby (scenario 4). From the resulting relatively large set of possible lines, the passenger can
choose the line with the least remaining journey time. The effect becomes more clear if the
passenger can already make such a decision on board line 1 (Scenario 5). The mean costs
savings in this example equals 139 minutes - which means considerable 14 percent on this
path leg from A to destination.
6.9.6 The search in general
The travel demand of an OD pair is entered at the origin zone. Several alternatives having
different headways and impedances may be available with the choice of the first line already.
The entire demand is now split up as is the case at all later decision points - between all
reasonable alternatives. How this happens exactly depends on the choice model used (see
"Choice models for boarding decisions" on page 434 and "The complete choice model" on
page 440).
Stochastic fuzziness becomes involved here in that all used lines possess a headway and the
wait time for a line is thus random. Even a line which is less attractive due to its larger
impedance can be given a certain percentage of the demand. If passenger information on
departures is available, this may occur exactly then for example, if the line with positive
probability departs so much earlier than other, qualitatively better alternatives that this time
advantage makes up for with its higher impedance.
As a result of this fundamental model assumption, the route search in the headway-based
assignment is not based on shortest path searches, but creates a directed decision graph for
each destination zone. Stops at which passengers are provided with several alternatives
represent the nodes of this decision graph, known as decision points. The paths in this graph
represent the various options to reach the destination zone.
Scenario 1 Scenario 2 Scenario 3 Scenario 4 Scenario 5
Share of Line 1 [%] 60.1 59.7 32.3 45.4 28.2
Share of Line 2 [%] 9.0 9.0 11.7 13.8 22.7
Share of Line 3 [%] 10.3 6.8 12.1 9.6 9.2
Share of Line 4 [%] 10.3 14.4 25.7 22.4 27.6
Share of Line 5 [%] 10.2 10.2 18.2 8.8 12.4
Mean Costs [min] 1839 1838 1820 1736 1700
Table 157: Line shares and the mean costs depending on the information available
446 PTV AG
The decisive factor is the assumption that, from the various options available, the passengers
will make their choice for the continuation of their journey at each stop on the basis of this
probability graph regardless of how they reached this stop.
Consequently, search and choice in the headway-based procedure are organized so that,
working backwards from each destination zone, all options are calculated to allow passengers
to move from the stops of the network towards the destination zone. The mean impedances of
the decision points for which a distribution has already been calculated are then used for the
iterative calculation of the distribution for more distant decision points.
In the course of this search, only such routes are maintained (this means only those paths are
loaded in the decision graph), which are positively assessed by the selected choice model. In
the case of passenger information, this means that a path at each traversed decision point is
probably the best option amongst all available alternatives. Similar statements apply for the
other choice models.
Optionally, all dominated paths can be singled out from these. A path is dominated by another
path if it applies to the same OD pair, uses the same sequence of time profiles (in the same
order), has the same start stop and end stop, yet has a longer total journey time (usually due
to the selection of less convenient transfer stops).
6.9.7 Example for the transport system-based assignment
Headway calculation
For the PuT supply displayed in illustration 154 the headway-based procedure determines the
headways for the analyzed time interval from 5:30 a.m. to 7:30 a.m. (120 minutes) illustrated
in Table 158 if these are calculated according to the method from mean headway (see
"Headway calculation" on page 432).
Route search
The case is, that passenger information on departure times exists and is also available on
board of the bus line. At route search, the procedure then determines two routes from A-Village
to X-City, if each of the two alternatives is with (even low) positive probability better than the
respective other one.
Route 1 (bus 1, no transfer) and
Route 2 (bus 1 and train, 1 transfer)
Probability becomes involved in that the wait time for the train in the case of a transfer is within
a range of between 0 and 60 minutes and no fixed transfer time has been assumed in advance.
If no extremely high transfer time penalty is used, some of the passengers will certainly use the
transfer option. This is because the train will leave (with a certain level of probability) only
shortly after the bus arrives and the passengers will thus arrive at their destination more
quickly.
Line Mean follow-up time Headway
Bus 1 120 / 3 * = 40 min 40 min
Train 120 / 2 ** = 60 min 60 min
* 3 departures in analyzed interval (6:10, 6:55, 7:25) from A-Village
** 2 departures in analyzed interval (6:25, 7:05) from Station
Table 158: Headway calculation for the example
447 PTV AG
Because the probability of obtaining an unfavorable connection in this case is significantly
higher, however, the majority of the passengers will continue their journey by bus.
The decisive factor is thus not only the mean wait time for the train in the example given, this
is 30 minutes but the complete range of possible wait times. Due to the existing passenger
information, each of the two routes thus receives precisely that portion of the demand that
corresponds to the chance of being the better of the two options.
Route Choice
In order to determine a distribution in the example given, specific impedance parameters have
to be used. These are set as follows.
Imp = PJT 1.0 + number fare points 0.0
Perceived journey time PJT = in-vehicle time 1.0
+ Access and egress time 1.0
+ Walk time 1.0
+ Origin wait time 1.0
+ Transfer wait time 1.0
+ Number of transfers 2 min
In this way, the impedances listed in Table 159 are calculated for a passenger arriving at the
railway station on Bus 1 for the remaining route legs.
From the impedances Imp1 and Imp2, the following percentages P1 and P2 of the OD demand
(in this case: 90 trips) result and thus the absolute number of trips on both routes (M1 or M2).
This occurs as follows.
The decision as to which of the routes is more attractive depends on whether the random
variable Imp2 is greater or smaller than the constant variable Imp1. Because Imp2 is uniformly
distributed in the interval [18, 78[ and Imp1 is equal to 33, the probability for choosing Route 2
is thus 0.25 according to the formula below.
This means that 90 0.25 = 22.5 passengers decide to travel by train and 90 0.75 = 67.5
passengers to continue their journey by bus.
Route 1 Route 2
Egress time, walk time 0 min 0 min
Run time 33 min 16 min
Transfer wait time 0 min randomly in [0 min, 60 min]
Transfer time penalty 0 2 min = 0 min 1 2 min = 2 min
IMP = PJT 1.0 33 min randomly in [18 min, 78 min]
Table 159: Impedance calculation for the routes in the example
25 . 0
60
15
18 78
18 33
= =
448 PTV AG
Illustration 154: Volume for headway-based assignment, transfer penalty 2 min
With any variation in the transfer penalty, this portion changes as shown in Table 160. For
other impedance parameters, the same applies.
The indicators for the relation between A-Village and X-City are shown in Table 161. These
values are mean indicators of both routes which weighted with the number of passengers of
each route are summarized for the impedance parameters used here.
Please pay particular attention to the transfer wait time of 7.5 minutes for Route 2. In this case,
the figure is not 60 / 2 = 30 minutes even though the train's headway is 60 minutes. This is due
to the fact that passengers will only take the train if the transfer wait time is short enough to
be precise, when this time (as seen above) is within a range of zero and 15 minutes. In all
other cases, there is no benefit in transferring. The 7.5 minutes transfer wait time in the choice
of Route 2 therefore represents a conditional expectancy value it is the mean wait time for
those passengers for whom Route 2 is in fact the best alternative.
Transfer time penalty Portion of Route 1 Portion of Route 2
0 min 0.717 0.283
1 min 0.733 0.267
2 min 0.750 0.250
5 min 0.800 0.200
10 min 0.883 0.117
Table 160: Changes to shares with variation of the transfer penalty
Route Set Pass. In-veh. time Pass. TWT Pass. Ride time Pass. NTR
1 67.5 67.5 45 min 67.5 0 min 67.5 45 min 67.5 0
2 22.5 22.5 28 min 22.5 7.5 min 22.5 35.5 min 22.5 1
Total 90 3667.5 min 168.75 min 3836.25 min 22.5
Mean 3667.5 / 90
= 40.75 min
168.75 / 90 =
1.875 min
3836.25 / 90 =
42.625 min
22.5 / 90 = 0.25
Table 161: Mean indicators for the headway-based assignment
90
23
67 67
Station X-City
A-Village
B-Village
449 PTV AG
6.9.8 Coordination
In VISUM, the coordination can be used for the headway-based procedure. This is realized by
so-called coordination groups.
6.9.8.1 Function of coordination groups
A coordination is defined between two or more lines to indicate that, for the passengers'
benefit, the trips of these lines are equidistant in terms of time on a shared route section . As a
consequence, the relevant line bundle is treated at the shared stops throughout the entire
procedure as a single line that operates with greater frequency. This results in a shorter mean
wait time than is the case with the (by default) assumed stochastic uniform distribution of the
relative position of the lines to each other.
A coordination group is a bundle of time profiles on a conjointly used passage. Two stops mark
the boundaries of the section. The significance of a coordination group lies in the calculation of
the mean wait time in the context of the headway-based assignment. In this assignment
procedure, it is usually assumed that the time interval between departures on different line
routes (strictly speaking: time profiles) is coincidental. With the aid of coordination groups, you
can display that certain line routes run in a rhythm of equal intervals to the advantage of the
passengers just like it is often the case in real life.

Please note that splitting up a line into two new lines, each with half the supply, does therefore
not lead automatically to the same result in calculation. It must not be assumed in advance
that a coordination exists. Coordinations have to be explicitly specified. illustration 155 shows
an example.
Illustration 155: Coordination of lines
Considering only the red-blue line, a passenger arriving randomly has a mean wait time of 5
minutes precisely half the headway.
Note: In the timetable-based assignment, coordination groups bear no meaning as departure
times can be gathered from the timetable here. In contrast, the headway-based assignment
calculates with average wait times only. Coordination groups come into play when it ought to
be expressed that those wait times are shorter than those arising from a coincidental
arrangement of the line routes.
H e a d wa y H
2
= 2 0 m i n
H e a d wa y H
1
= 2 0 m i n
H e a d wa y H = 1 0 m i n
1 2
b l u e
r e d
r e d - b lu e
450 PTV AG
If this line is split up into a blue and a red portion without defining a co-ordination, a mean wait
time of 6:40 minutes results after the headway calculation. This is the expected value of the
offset to the next departure of one of the two lines and, depending on the relative position of
the two lines to each other, this offset can be somewhere between 0 and 20 minutes.
Defining a coordination indicates that the interval between departures of the red and the blue
line remains constant at 10 minutes. As in the initial situation, this results in a mean wait time
of 5 minutes.
6.9.8.2 Matched transfers
The transfer time between two lines at a stop is normally a combination of the transfer walk
time taken from the transfer walk time matrix (see User Manual, Chpt. 2.23.2, page 328) and
the random wait time for a trip of the successor line. This results from the fundamental model
assumption that passengers a priori have no information on the exact departure times of the
lines, but only know their in-vehicle times and headways.
In some cases, however, it is desirable to model that the transfer time between two lines is not
stochastic, but assumes a fixed value. This is particularly important in networks with longer
headways, in which the existence of coordinated connections is nevertheless assumed.
In this case, for a pair of time profiles at a stop, a so-called matched transfer can be defined.
Transfers from one time profile (see User Manual, Chpt. 2.23.2, page 328) to the other then
require precisely the specified duration each time (see User Manual, Chpt. 6.2.3.2, page 958).
6.9.8.3 Example for the coordination
For a passenger, a single line route with headway of 20 minutes means a mean wait time of 10
minutes. Whether the introduction of a second line route of the same headway means that the
wait time will be reduced to 50% depends on its concrete temporal position. A sequence like
8:00 8:02 8:20 8:22 - ... for example does not yield a noteworthy improvement.
If, however, two such line routes are coordinated, the headway-based assignment assumes
that the departures are of equal intervals and thus timed like this: 8:00 8:10 8:20 8:30 -
.... As a result, the average wait time is reduced to 5 minutes. Without coordination, all
positions in the timetable are considered equally probable. The expected value for the wait
time is then 6:40 minutes.
Coordination only acts on those stops (on the section marked by the start point and end point)
at which the coordinated time profiles actually stop. If only a subset of the coordinated bundle
stops at a stop, only the time profiles that stop are considered coordinated at that stop.
If there is an overlap between the coordination groups to be defined, only the first coordination
group of each time profile item is considered. In this case, a warning is triggered at the
beginning of the assignment.
Note: The coordination of time profiles ends at the ToStop, that is, the arrival times of the time
profile are still coordinated at that stop but the departure times are not.
Note: If a network-wide coordination is assumed for a headway-based assignment, option
Coordination everywhere can be used during the assignment. Coordination groups are
then redundant.
451 PTV AG
6.9.8.4 Assume coordinated time profiles to be undistinguishable
For identical headways, the coordination's mechanisms of action is clearly defined. Since
coordination groups can be defined for arbitrary time profiles in VISUM, however, there is not
always a natural definition of the aggregate headway.
The approach implemented so far, which corresponds with the procedure in the program VIPS,
is based on the assumption that the passengers can differentiate between the individual time
profiles in a coordinated bundle and also make their choice against attributes of the respective
time profile.
The new approach, which is realized in the program via the option Assume coordinated time
profiles to be undistinguishable, is based on the following algorithm. T
i
are the headways of
the coordinated time profiles.
In a first step, the aggregate headway T for the bundle is set as follows.
T := 1 / (1 / T
1
+ ... + 1 / T
m
)
This is the harmonic mean of the given T
i
. The number of services corresponding to this
headway is equal to the sum of the number of services of the individual time profiles.
Example: T
1
= 6, T
2
= 7.5 (i.e. 10 + 8 services per hour) yields an aggregate of T = 10/3
which also corresponds to 18 services per hour.
For each time profile, the proportion of the total number of services is given by
i
= T / T
i
.
This fraction is also used as the relative share of the demand within the time profile bundle,
i.e. p
i
:=
i
. The aggregate impedance is again set to C := c
1
p
1
+ + c
m
p
m
with c
i
=
impedances of the time profiles.
Using the standard algorithm (see "Route search" on page 446 and "Route Choice" on
page 447), the virtual aggregate time profile m* with headway T and impedance C is
compared with the other time profiles
Model approach
Here, the general assumption is that the time profiles in the coordinated time profile bundles
are not distinguishable. The time profile attributes headway and impedance are irrelevant.
Instead, the headway is calculated with the focus on the number of services.
As a consequence, each time profiles proportion of the total number of services can be used
as demand share per time profile. Passengers that cannot differentiate between the different
time profiles of a time profile bundle will automatically board the first service available.
Therefore, the passenger volume of each contained time profile is proportional to the
alternative's number of services.
Furthermore, the aggregate impedance is defined as the weighted mean of the single time
profiles impedances, this time using the service frequency shares
i
as weights. This makes
sense because the resulting aggregate is the mean impedance of all services. For the
passenger, this is the expected impedance when boarding the first available service of the TP
bundle.
Example
The example illustrates the difference between the already existing approach and the new one:
For the undistinguishable approach, the aggregate headway T is equal to 6/7, i.e. only 46
seconds. The aggregate impedance is C = 22.77. This value is much larger than before since
the high-impedance time profile 1 plays a more significant role now.
452 PTV AG
6.10 Timetable-based assignment
A search method is called timetable-based if all services of PuT lines are taken into account
with their precise departure and arrival times.
Timetable-based methods are suitable for assignments and the calculation of indicators, when
a line network plan and a detailed timetable are available for the PuT supply analyzed. They
take the coordination of the timetable into account and thus ensure very precise results of the
indicator data calculation.
The timetable-based method calculates connections for each OD pair. In the Search it is
assumed that the passengers have timetable information available and choose their access
time according to the departure on the first PuT line. During the search, the user can influence
the kind of connections found in different ways by means of search impedance. For the
connection search, two variants (branch & bound search and shortest path search) are offered
that represent the different compromises between the number of alternatives on the one hand
and the memory and computing time requirements on the other.
During preselection of connections, the connections yielded by the search algorithm are re-
analyzed by means of general criteria as to whether some of them are of a significantly lower
quality and can thus be deleted.
During the choice, the demand is distributed to the remaining alternatives based on one of the
models described above. The independence of connections can be taken into account if
required.
6.10.1 Evaluation of the timetable-based assignment
The timetable-based assignment is characterized by the following features.
Using the branch & bound option (see "The variant Branch and Bound" on page 453), the
procedure calculates all suitable connections throughout the entire analysis period. This
also includes the calculation of several connections with different impedances (for example
shortest time and minimum transfer connections) for a departure time. In the case of a
monocriterion shortest path search (see "The variant Shortest path search" on page 454),
only one connection is calculated for each departure time, as this reduces the memory and
computing time requirements. The search can be influenced by means of the search
impedance definition.
Branch & Bound search is suitable for the analysis of a period (see "The variant Branch and
Bound" on page 453) - for example the whole day or several hours. When performing a
search at a specific time (e.g. in the case of a graphical route search), the shortest path
search is recommended (see "The variant Shortest path search" on page 454).
TP Impedance Headw
ay
Distinguishable (Standard) Undistinguishable
1 24 1 0.0166 0.7692
2 20 5 0.3366 0.1538
3 16 10 0.6466 0.0769
453 PTV AG
Chapter 6.10: Timetable-based assignment
The actual transfer wait time, and thus the coordination of the timetable, is taken into
account.
All indicators in the analyzed time interval can be calculated.
The decision model for the connection choice (see "Connection Choice" on page 458)
models the actual decision behavior of the passengers realistically, because a passenger
usually has some information on the PuT supply (connection search) and then makes his
choice from the connections offered (connection choice).
6.10.2 Connection search
For the connection search, two variants are provided.
6.10.2.1 The variant Branch and Bound
For each origin zone, a search tree of suitable partial connections is generated which stores all
sufficiently suitable connections from this origin zone. This means that not only the best
connection is found for an OD pair, but a large number of good connections. In this way, a very
selective distribution of travel demand is possible.
A search impedance is used in order to evaluate the quality of connections. For all (partial)
connections found in the search, the search impedance is calculated using the following
equation.
SearchIMP = JRT FacJRT + NTR FacNTR + TSys-Imp FacTSys-Imp + VehJ-Imp
FacVehJ-Imp
In addition to the journey time and the number of transfers, the equation includes fares
classified on the basis of the transport system in TSys-Imp, that is the influence of fares can
already be taken into account during the search. Via VehJ-Imp, also the vehicle journey-
specific impedance is added. It results from two freely selectable attributes of the vehicle
journey items as boarding supplement and as general discomfort term. In this way,
individual vehicle journeys can be favored or penalized.
For the evaluation of a newly found (partial) connection to a destination or a transfer node,
the following rules apply. The new partial connection is deleted if the following applies (see
"Bounding" on page 454).
Search impedance of the connection > minimum search impedance factor + constant,
or
Journey time of the connection > minimum journey time factor + constant, or
Number of transfers of the connection > minimum number of transfers + constant.
These rules ensure that inconvenient partial connections can be eliminated while the
search is progressing.
It is possible to specify an upper limit for the number of transfers in a connection.
Dominance
Comparisons of connections in pairs help searching as efficiently as possible. This is feasible
if a connection is already found which fulfils both criteria.
It is temporally encompassed by the option.
It is not worse in any qualitative aspect.
The previous definition of dominance was:
454 PTV AG
A connection c dominates a connection c, if
c lies within the time interval of c
NTR(c) NTR(c)
Imp(c) Imp(c)
Real inequality applies to one of the three criteria above.
This results in the following changes in the definition of dominance.
For comparisons of two connections without a defined temporal position, rule 1 changes to
RideTime(c) RideTime(c).
The other rules remain unchanged. Thus still applies for example: NTR(c) = Rounding up (
(NumLegs(c) 1) / 2 ).
New connections with a departure time are always compared with all connections that do
not have a departure time.
Dominance may exist in both directions.
New connections with PuTAux yet without a departure time are always compared with all
other connections. Dominance may exist in both directions. This distinguishes these
connections from pure walk links which cannot be dominated themselves as their number
of transfers is optimal.
Bounding
For the evaluation of a newly found (partial) connection to a destination or a transfer node, the
following rules apply. The new partial connection is deleted if the following applies.
Search impedance of the connection > minimum search impedance factor + constant, or
Journey time of the connection > minimum journey time factor + constant, or
Number of transfers of the connection > minimum number of transfers + constant.
These criteria are not applied in pairs but always regarding the optimum to a destination
determined so far. As a basic principle, no connections are deleted that are optimal themselves
in any dimension even if they break the rule in another dimension.
No changes occur since SearchImp, journey time and NTR are also defined when PuTAux is
used.
6.10.2.2 The variant Shortest path search
This option uses the "best" route search strategy on the basis of the particular time of departure
and the time of arrival. A shortest-path algorithm based on this data calculates the best
connection between two traffic zones for a particular departure time. For different times of
departure, various "best" connections may be calculated which may differ by the used PuT
lines and/or transfer stops. To determine all "best" connections within the analyzed time
interval the shortest path algorithm is performed several times for all possible departure times
within the analysis time interval.
Since in some cases several connections are possible for a given time of departure, a definition
of "best connection" is required for these search procedures. For this purpose VISUM provides
an impedance function which increases the impedance of a connection for each transfer by the
transfer penalty. A low penalty has the result that connections which take the least time are
favored, while a high transfer penalty gives priority to connections with a lower number of
transfers.
455 PTV AG
Determination of all possible start times for trips which originate in traffic zone i. The start
times result from the departure times of PuT lines at stops which can be reached from zone
i via a connector.
In the example, the start times correspond with the departure times of bus line 1 from A-
Village (6.10, 6.55, 7.25), because A-Village is only serviced by one bus line and an access
time of 0 minutes is assumed.
For every start time one of the two following steps is executed.
Either a monocriterion shortest path search is carried out which searches for the "best" path
from traffic zone i to traffic zone j starting at the given time. The search procedure identifies
the path with the lowest impedance as the best path. The impedance of the path is
measured in minutes and is a linear combination of journey time and number of transfers.
It consists of the following time components.
Access time [min]
In-vehicle time [min],
Transfer walk time between two transfer stops [min],
Transfer wait time [min]
Egress time [min]
Number of transfers [-] transfer penalty [min] (adjustable).
This lowest impedance path represents a connection, because the used sequence of lines
and the exact departure and arrival times at boarding stop, transfer stops, and alighting
stop are known.
Or the connection with the minimum journey time (so-called bicriterion shortest path
search) is calculated for each permitted number of transfers (for all integer values 0 and
max. number of transfers). If the calculation returns identical journey times for different
numbers of transfers, the program only stores the connection with the lowest number of
transfers (dominance).
6.10.3 Connection preselection
The preselection of connections compares and evaluates all found connections. This includes
the check, whether a connection could be replaced by a more suitable one and thus can be
deleted. Only convenient connections are offered to the passengers for the connection choice.
In order to identify inconvenient connections, the following exclusion rules are applied in turn.
Search impedance of the connection > minimum search impedance factor + constant, or
(no limitations; just branch & bound)
Journey time of the connection > minimum journey time factor + constant
(unless the connection is optimal with respect to the number of transfers)
Number of transfers of the connection > minimum number of transfers + constant
(unless the connection is optimal with respect to the journey time)
The factors and constants can be set by the user.
6.10.4 Perceived journey time PJT of a connection
The impedance is a linear combination of perceived journey time (see "Perceived journey time"
on page 456), fare, T(early) and T(late). T(early) and T(late) thus express the temporal
utility of a connection (see "Temporal utility of a connection" on page 457).
456 PTV AG
6.10.4.1 Perceived journey time
PJT [min] =
In-vehicle time FacIVT any (in)direct attribute of vehicle journey items
+ PuTAux time FacAXT (in)direct TSys attribute
+ Access time FacACT
+ Egress time FacEGT
+ Transfer walk time FacWT
+ Number of transfers FacNTR
+ Number of operator changes FacNOC 1
+ Extended impedance Factor
Notes
PuT-Aux time
The time spent in a transport system of the PuT-Aux type enters the PJT as a separate
value and can be weighted by any transport system attribute. It is furthermore required as
a skim value.
Modeling Bonus and Malus
The in-vehicle time can be multiplied by an attribute of the vehicle journey items (and the
PuT-Aux time by a TSys attribute respectively) in order to model the vol/cap ratio (for
example the availability of seats) or other aspects of usability (for example the level of
comfort).
Number of transfers
The PuT line TSys and the PuT-Aux TSys enter the calculation of the number of transfers
on a par.
Number of operator changes
Operator changes cannot occur due to PuT-Aux path legs.
Origin wait time
With the following equation, the origin wait time, OWT, can be determined from the service
frequency of all connections.
OWT = A (assignment time interval / service frequency)
E
.
With A = 0.5 and E = 1, the origin wait time corresponds to half the mean headway.
With A = 1.5 and E = 0.5, a root function is created which assumes that passengers have
better knowledge of timetables in the case of low service frequency.
The origin wait time is the same for all connections of an OD pair. Including them in the PJT is
therefore just like a constant supplement. The OWT output as a skim matrix, however, can be
important for the network analysis.
Transfer wait time
The transfer wait time models smooth transfers in zero time or slightly more than zero time.
457 PTV AG
The extended transfer wait time models that transfers are ideal not in zero time (or slightly
more) but if they take a few minutes. A lot of timetable information retrieval systems also do not
offer connections that contain "smooth" transfers.
With the extended transfer wait time, the user can also "penalize" transfers in VISUM that are
too short. For this, the program uses a non-linear function which calculates a weighted wait
time that depends on the user-defined ideal transfer wait time, which then enters the perceived
journey time. Instead of the regular transfer wait time, the extended transfer wait time can enter
the PJT calculation. But it can also be saved as a separate skim.
The used weighting function f takes the following shape.
As an argument, the actual transfer wait time t is set, which is the time that passes between
the arrival of the passenger at the stop point and the departure of the service trip.
The weighted wait time f(t) is thus defined as
(t - t
0
)
n
+ c, falls t < t
1
, and
f(t) = t, if t t
1
.
t1 and c result from the boundary conditions f(t
1
) = t
1
and f'(t
1
) = 1, that is from the
differentiable composition of both parts of the function at position t
1
.
Essential is: t
0
is the transfer wait time considered ideal. For the extended transfer wait
time, this variable may depend on the required walk time and thus needs to be
parameterized as follows:
Factor times walk time plus constant
Due to the polynomial shape of f, the weighted wait time f(t) is the least precisely at the position
t = t
0
.
Around t
0
, f(t) increases symmetrically.
If t increases, function f(t) approaches the linear asymptote t.
Example
By default, n = 2 and t
0
= 5 is set.
Due to the boundary conditions f(t
1
) = t
1
and f'(t
1
) = 1, t
1
= 5.5 and c = 5.25 results from these
parameters.
For a transfer with time t = 0, weighting is calculated as follows, i.e. a very high penalty
term:
f(0) = t
0
2
+ c = 25 + 5.25 = 30.25
A transfer with time t = 3 results in a considerably better value:
f(3) = (3 - t
0
)
2
+ c = 2
2
+ 5.25 = 9.25
A transfer with time t = 5 reaches the optimum:
f(5) = (5 - t
0
)
2
+ c = 0
2
+ 5.25 = 5.25
If t continues to increase, the weighting deteriorates again, for example with t = 10:
f(10) = (10 - t
0
)
2
+ c = 25 + 5.25 = 30.25
6.10.4.2 Temporal utility of a connection
In the timetable-based method, the temporal utility of a connection is modeled as follows.
458 PTV AG
T
a
i
Early
= amount of time that connection i departs earlier than desired for departure
interval a ( time series); equals zero, if i departs within a or after a.
T
a
i
Late
= amount of time that connection i departs later than desired for the departure
interval a ( time series); equals zero, if i departs within a or before a.
T
a
i
Early
Fac
Tearly
+ T
a
i
late
Fac
Tlate
= temporal distance between connection i and
intervall a. The first factor controls the sensitivity of passengers towards earlier departures,
the second the sensitivity towards later departures.
This temporal distance is included as a further summand in the definition of impedance, in
order to impede lower utilities.

Table 162 shows an example for the calculation of T
early
und T
late
in the time intervall [06:00
AM;07:00 AM].
6.10.4.3 Fare
If a zone-based ticket type is used, PuT-Aux path legs are disregarded. Distance-based ticket
types are evaluated analogously to PuT-TSys because fare points can also be assigned to
PuT-Aux (see "Revenue calculation using the fare model" on page 597).
6.10.5 Connection Choice
The connection choice distributes the demand of a relation onto the found connections. In
order to do this, the connection impedances are calculated; they include the perceived journey
time PJT, the fare and the temporal utility of a connection (see "Perceived journey time PJT of
a connection" on page 455). For the distribution models, these impedances serve as an input
for calculating the shares of the connections in the travel demand (see "Distribution models in
the assignment" on page 289). The independence can also be included in the distribution rule,
if required (see "Independence of Connections" on page 460).
Note: For connections with no temporal position, T is always zero
Departure T T
early
T
late
5:30 30 30 0
6:00 0 0 0
6:40 0 0 0
7:00 0 0 0
7:10 10 0 10
Table 162: Calculation of the temporal distance
Tearly := { desired dep.Time actual dep.T if actually < desired, else 0
Tlate:= { actual dep.Time desired dep.T if actually > desired, else 0
459 PTV AG
6.10.5.1 Distribution of trips onto connections
The impedance of a connection i used in the connection choice in a time interval a is calculated
as follows.
Optionally, each parameter which is input in the impedance can be individually Box-Cox
transformed. This does not affect the actual choice model. Any utility function can thus still be
applied to the total impedance even when using the BoxCox transformation.
The impedance calculation is not linked to the actual connection choice, that is, even when
calculating the BoxCox transformation, Logit does not necessarily have to be used. Any other
utility function can be selected instead.
The impedance calculation is as follows.
For i = 1, ..., n are x
i
the different path attributes. Here, the first m of them without restrictions
are to be BoxCox-transformed (namely each into parameter
i
).
i
stands for the respective
coefficient. Then the following applies
where
By including this impedance in one of the distribution models Kirchhoff, Logit, Box-Cox or
Lohse (see "Distribution models in the assignment" on page 289), VISUM then determines the
utility of a connection in a given time interval and ultimately its percentage of the demand for
this interval. The independence can also be included in the distribution rule, if required (see
"Independence of Connections" on page 460).
As before, the proportion of a connection i of the total demand is calculated as follows.
Here, g is the selected utility function (always antitonic). In the case of Logit thus applies
g(x) = e
-bx
.
IMP = PJT
i
Fac
PJT
+ Fare Fac
Fare
+
T
a
i
early FacTearly +
T
a
i
late FacTlate
( )

+ =
+
=
=
n
1 m i
i
x
i
m
1 i
i
x
i
f
i i
W
( )
=
=
0
1 x
0 x log
x
i
f
i
i
i
i
( )
( )
,
j
j
W g
i
W g
:
i
p
=
460 PTV AG
6.10.5.2 Independence of Connections
All distribution models (see "Distribution models in the assignment" on page 289) presented
cannot, in their basic form, take into account interactions between different connections in a
timetable-based assignment. However, ignoring this aspect can be a drawback.
In order to model interactions, one defines functions w
i
, which describe the impact of other
connections on a connection i. The value range of w
i
is the interval [0.1]. If j has no impact on
i, then w
i
(j) = 0. If i and j are absolutely equal, then w
i
(j) = 1, meaning it is always w
i
(j) = 1.
The following values are used to calculate w
i
(j).
The temporal proximity of the connections with regard to departure and arrival
The advantage of i over j in terms of the perceived journey time
y
i
(j) := PJT
j
- PJT
i
The advantage of i over j in terms of the fare
z
i
(j) := F
j
- F
i
Thus, w
i
is defined as follows.
,
where and
s > 0 are internal parameters for controlling the influence of the three values. c is a constant that
controls the absolute effect of the second value. It is user-defined within [0.1].
The first value describes the temporal proximity of i and j. If the times are the same, then x
i
(j)
= 0, so that this value is equals to 1. If the time difference is x
i
(j) s
x
, the value becomes zero
and w
i
(j) = 0 also applies. Thus, s
x
is the maximum temporal distance in which j can effect i.
The second value lies between 1 (in case of absolute equality in the context of y
i
(j) = 0 and z
i
(j)
= 0) and 1 - c (when there is a significant difference between i and j). As with s
x
, s
y
+
or s
y
-
is the
maximum temporal advantage or disadvantage of i, in which j can possibly have an impact.
Notes: As can be seen from the definition, when using the BoxCox transformation for x
i
generally x
i
0 needs to apply. In case of
i
= 0, even x
i
> 0 needs to be true. If this rule is
violated during the run time, the assignment is terminated with an error message.
Due to a BoxCox transformation or caused by negative coefficients, W
i
itself can be negative.
In that case, only the Logit utility function can be used, otherwise the assignment is
terminated with an error message.
( )
2
i
ANK
j
ANK
i
ABF
j
ABF
j
i
x
+
=
( )
( )
( ) ( )
+

+
=
z
s
y
s
j
i
z
y
s j
i
y
z
s
, 1 min c 1
x
s
j
i
x
1 : j
i
w
( )
( )

<
=
+
0
0
:
j y if s
j y if s
y
s
i y
i y ( )
( )

<
=
+
0
0
:
j z if s
j z if s
z
s
i z
i z
461 PTV AG
With regard to the fare, the same applies to s
z
. The default setting leads to the following
relation: s
y
-
= 2s
y
+
and s
z
-
= 2s
z
+
. As a result of this asymmetry, in the case of two connections
with temporal proximity, the better is favored, because its influence on the worse alternative is
greater than vice versa. In principle, users should always specify Independency coefficients for
high or low quality in the form of IndCoeffQualityHigh (ECQH) < IndCoeffQualityLow (ECQL).
When violating this rule, a warning appears at the start of the assignment (or an error message
in the window).
Overall, the following applies:
s
x
= min (2 mean wait time of a random passenger between the first and the last departure, maximum
time slot)
s
y
+
= ECQH mean PJT in the total assignment period
s
y
-
= ECQG mean PJT in the total assignment period
s
z
+
= ECQH mean fare in the total assignment period
s
z
-
= ECQL mean fare in the total assignment period
If no fares are available (i.e. FP
i
= 0 for all i), then s
z
= 1 is set.
The attribute independence of a connection is now defined as follows:
Here, n is the total number of connections.
Distribution models with independence
If independence is used for connection choice, then this attribute must be integrated in the
distribution model. In the version described above, for each time interval a the utility U
i
a
of a
connection i was calculated. From this, its percentage in terms of the demand was determined
per time interval. If independence is applied, U
i
a
EIG
i
replaces U
i
a
, i.e. the following applies.
This linear dependence on the independence attribute ensures that k simultaneous, identical
alternatives are treated as a single connection. According to the definition of IND, the
independence of each of such k alternatives is precisely 1 / k (if no other connections with
temporal proximity have an effect). As a result, the total of its weights in the distribution formula
is equal to the weight of a single, non-multiplied connection of the same kind.

Note: Only the temporal positions, the PJT values and the fares are compared; service trip
item data is not evaluated.
( ) ( )

=
+
=
=
=
n
i j , 1 j
j
i
w 1
1
n
1 j
j
i
w
1
:
i
EIG
=
n
1 j
j
EIG
a
j
U
i
EIG
a
i
U
a
i
P
462 PTV AG
Comparison of the distribution models with independence
In Table 164 to Table 167 the different distribution models are compared with each other, with
and without independence. The procedure parameters are chosen as in Table 163.
Connection data that differs from the respective previous example is highlighted by bold type
in Table 164 to Table 167 . All assignment shares are given as percentages.
Kirchhoff = 4
Logit = 0.25
Box-Cox = 1 and = 0.5
Lohse = 4
PJT formula PJT = JT + 2 TWT + 2 NTR
IMP formula IMP = PJT + 4 fare
IND parameter c = 1
Table 163: Procedure parameters for the comparison of the distribution models
Connection data Distribution without IND Distribution with IND
No. Dep Arr
P
J
T
Fare
K
i
r
c
h
h
o
f
f
L
o
g
i
t
B
o
x
-
C
o
x
L
o
h
s
e
K
i
r
c
h
h
o
f
f
L
o
g
i
t
B
o
x
-
C
o
x
L
o
h
s
e
1 10 30 20 3.00 33.3 33.3 33.3 33.3 33.3 33.3 33.3 33.3
2 30 50 20 3.00 33.3 33.3 33.3 33.3 33.3 33.3 33.3 33.3
3 50 70 20 3.00 33.3 33.3 33.3 33.3 33.3 33.3 33.3 33.3
Table 164: Example 1 Initial situation
No. Dep Arr
P
J
T
Fare
K
i
r
c
h
h
o
f
f
L
o
g
i
t
B
o
x
-
C
o
x
L
o
h
s
e
K
i
r
c
h
h
o
f
f
L
o
g
i
t
B
o
x
-
C
o
x
L
o
h
s
e
1 10 30 20 3.00 25 25 25 25 33.3 33.3 33.3 33.3
2 30 50 20 3.00 25 25 25 25 16.7 16.7 16.7 16.7
3 30 50 20 3.00 25 25 25 25 16.7 16.7 16.7 16.7
4 50 70 20 3.00 25 25 25 25 33.3 33.3 33.3 33.3
Table 165: Example 2 Isochronous, identical pair of connections
No. Dep Arr
P
J
T
Fare
K
i
r
c
h
h
o
f
f
L
o
g
i
t
B
o
x
-
C
o
x
L
o
h
s
e
K
i
r
c
h
h
o
f
f
L
o
g
i
t
B
o
x
-
C
o
x
L
o
h
s
e
Table 166: Example 3 Identical pair of connections with high temporal proximity
463 PTV AG
The fact that, without IND being applied the connections 1, 2 and 4 have the same number of
passengers in all cases shows, that the interactions between different alternatives ought to
be taken into account to a higher degree in this case. It becomes apparent that then better
results are achieved with all distribution models.
6.10.5.3 Example for the connection choice
The effect of the connection choice for the timetable-based method is shown with the results of
the connection search regarding a 10-minute transfer penalty. The branch & bound search is
used. This search returns the five connections shown in Table 168. A monocriterion shortest
path search however would only find the connections 1, 3 and 5, as they have the lowest
impedance of all the connections of their departure times. The impedance (= perceived journey
time) results from the weighted sum of the following skims: journey time (JRT), transfer wait
time (TWT) and number of transfers (NTR).
1 10 30 20 3.00 25 25 25 25 32.7 32.7 32.7 32.7
2 30 50 20 3.00 25 25 25 25 17.3 17.3 17.3 17.3
3 32 52 20 3.00 25 25 25 25 17.3 17.3 17.3 17.3
4 50 70 20 3.00 25 25 25 25 32.7 32.7 32.7 32.7
No. Dep Arr
P
J
T
Fare
K
i
r
c
h
h
o
f
f
L
o
g
i
t
B
o
x
-
C
o
x
L
o
h
s
e
K
i
r
c
h
h
o
f
f
L
o
g
i
t
B
o
x
-
C
o
x
L
o
h
s
e
1 10 30 20 3.00 25.9 26.7 26.2 25.1 31.9 32.6 32.2 31.2
2 30 50 20 3.00 25.9 26.7 26.2 25.1 20.2 20.7 20.4 19.8
3 32 47 20 3.30 22.3 19.8 21.3 24.6 16.0 14.1 15.2 17.8
4 50 70 20 3.00 25.9 26.7 26.2 25.1 31.9 32.6 32.2 31.2
Example 4 Similar pair of connections with high temporal proximity (connection 3 now includes transfer)
No. Dep Arr
P
J
T
Fare
K
i
r
c
h
h
o
f
f
L
o
g
i
t
B
o
x
-
C
o
x
L
o
h
s
e
K
i
r
c
h
h
o
f
f
L
o
g
i
t
B
o
x
-
C
o
x
L
o
h
s
e
1 10 30 20 3.00 23.5 21.9 22.8 24.6 26.5 24.9 25.8 27.7
2 30 50 20 3.00 23.5 21.9 22.8 24.6 20.1 18.9 19.6 21.0
3 32 44 17 3.30 29.6 34.3 31.5 26.1 26.9 31.4 28.7 23.6
4 50 70 20 3.00 23.5 21.9 22.8 24.6 26.5 24.9 25.8 27.7
Table 167: Example 5 - Differing pair of connections with moderate temporal proximity
Table 166: Example 3 Identical pair of connections with high temporal proximity
464 PTV AG
Table 169 shows the impedances of the connections. As T depends on the desired departure
time of the passengers, different impedance values result for the various time slices of travel
demand. Thus, the impedances of the first two connections are lower in the first interval,
whereas those of the last three connections are lower in the second interval. The impedance
definition is set in such a way, that the following applies:
R
i
a
= PJT
i
1.0 + T
i
a
early 1.0 + T
i
a
late 1.0
A distribution rule (here Kirchhoff with = 3) is then used to calculate the shares P
i
a
which are
allocated to the individual connections. The independence is ignored in this formula. As shown
in Table 170, all five connections are assigned non-zero percentages of the travel demand per
time interval.
Conn. i Dep JRT
i
TWT
i
NTR
i
PJT
i
= JRT
i
+ TWT
i
Fac
UZ
+ NTR
i
Fac
NTR
1 6:10 28 min 3 min 1 28 + 3 2 + 1 2 = 36
2 6:10 45 min 0 min 0 45 + 0 2 + 0 2 = 45
3 6:55 45 min 0 min 0 45 + 0 2 + 0 2 = 45
4 7:25 28 min 8 min 1 28 + 3 2 + 1 2 = 36
5 7:25 45 min 0 min 0 45 + 0 2 + 0 2 = 45
Fac
TWT
= 2, Fac
NTR
= 2
Table 168: Result of connection search (transfer penalty 10 min, parameter file TIMETAB1.PAR)
Conn. i Dep
T
i
1
5:30-6:30
T
i
2
6:30-7:30
R
i
1
5:30-6:30
R
i
2
6:30-7:30
1 6:10 0 min 20 min 36 + 0 = 36 36 + 20 = 56
2 6:10 0 min 20 min 45 + 0 = 45 45 + 20 = 65
3 6:55 25 min 0 min 45 + 25 = 70 45 + 0 = 45
4 7:25 55 min 0 min 46 + 55 = 101 46 + 0 = 46
5 7:25 55 min 0 min 45 + 55 = 100 45 + 0 = 45
Table 169: Temporal distances T and impedances R of the connections for the two analyzed intervals of
travel demand
Conn.i Dep
P
i
1
5:30-6:30
P
i
2
6:30-7:30
Vehicle
journeys M
i
1
5:30-6:30
Vehicle
journeys M
i
2
6:30-7:30
Trips
5:30-7:30
1 6:10 57% 13% 30 0.57 = 17 60 0.13 = 8 25
2 6:10 30 % 8% 30 0.30 = 9 60 0.08 = 5 14
3 6:55 7% 27% 30 0.07 = 2 60 0.27 = 16 18
4 7:25 3% 25% 30 0.03 = 1 60 0.25 = 15 16
5 7:25 3% 27% 30 0.03 = 1 60 0.27 = 16 17
Table 170: Distribution of trips to the connections (Kirchhoff, = 3)
465 PTV AG
Illustration 156: Network volume for timetable-based assignment (parameter file timetab1.par)
6.10.6 Handling of public transport systems of the PuT-Aux type
The following applies for transport systems of type PuT-Aux.
They are considered in the timetable-based assignment and also via the menu Graphic >
Shortest path.
They are convenient for modeling inferior transport supply without timetables. These are for
example
Park & Ride
Local public transport with dense headway within a network that is otherwise timetable-
based
Taxis
They are only relevant on links and turns. By defining permissions of PuT-Aux TSys to
these objects, the subnetwork which is enabled per PuT-Aux TSys is defined. This
information is not relevant for connectors, nodes or stop points.
Alike PuT-Walk TSys, PuT-Aux TSys are permitted for PuT modes. In case of assignments of
demand segments of such modes, passengers can use path legs with the PuT-Aux, too,
namely those between two nodes that are connected by links for which the PuT-Aux transport
system is permitted. These nodes need to be accessed by walk links however, or be directly
connected to a zone or stop area.
During the assignment, a change to a PuT-Aux path leg counts as a transfer.
The extended modularized procedure can be used for example, to export and import fares
(see "Opening of the timetable-based assignment" on page 466)
S 100 % 100 % 30 60 90
Conn.i Dep
P
i
1
5:30-6:30
P
i
2
6:30-7:30
Vehicle
journeys M
i
1
5:30-6:30
Vehicle
journeys M
i
2
6:30-7:30
Trips
5:30-7:30
Table 170: Distribution of trips to the connections (Kirchhoff, = 3)
90
41
49 49
Station
X_city
A_village
B_village
466 PTV AG
Pre-calculation of path legs
The set of PuT-Aux TSys permitted in an assignment directly affects the path legs to be
calculated because every start node of PuTAux paths represents a potential target of PuT walk
links. This is taken into account when pre-calculating the walk links and PuT-Aux paths.
Adjustment of the connection search
Analogous to walk links, a path leg is created for each PuT Aux path. In any case, the trivial
PuT-Aux transfers at nodes appear as individual path legs in any case. Path legs are sorted
separately by type: PuT-Line, PuT-Walk, and PuT-Aux.
Analogous to the reference to the index of the first walk link path leg for an origin, a reference
to the index of the first PuT-Aux path leg is logged.
For path legs with PuT-Aux TSys, too, journey time, number of transfers and the impedance by
transport system are clearly defined. In particular the link attributes Imp/km, Imp/FarePoint
and Imp/AddVal are available for PuT-Aux TSys.
6.10.7 Opening of the timetable-based assignment
For some projects particularly in connection with demand modeling (see "Demand model" on
page 103)a (time-consuming) timetable-based assignment is carried out several times within
the same process.
Example
First of all PuT skims are determined, then the mode choice is made and finally the actual PuT
assignment is conducted. As the PuT skim calculation already determined all connections, it
would be advantageous to skip the repetition of the connection search - which is one of the
steps of the subsequent assignment by default - and to store and re-use the connections from
the skim value calculation instead. The assignment would then be restricted to the Choice step
(see "Connection Choice" on page 458).
During the timetable-based assignment, the connections can either be determined by a Search
(see "The variant Branch and Bound" on page 453 and "The variant Shortest path search" on
page 454) or alternatively be read from file or taken from a previously calculated assignment.
Connection export and import
The option of saving (see User Manual, Chpt. 6.2.4.8, page 984) connections to file in order to
import (see User Manual, Chpt. 13.3, page 1406) them later opens the assignment also for
users who want to use their own search and choice procedures. The timetable-based
assignment has such a modular structure that Search and Choice can be performed
independently of each other.
The import of already loaded connections is offered as a separate procedure called
Connection import. It provides a proper assignment result. All possible evaluations (flow
bundle, path list, operational indicators etc.) are available as usual (see User Manual, Chpt.
13.3, page 1406).
If the Search is to be performed externally, the external procedure has to generate a file in
the VISUM connection format, which then can be loaded instead of theVISUM search.
If the Choice is to be performed externally, the user exports the connections (without
volumes). The external choice then assesses the connections, allocating a specific volume
to each connection. Again the loaded connections are stored in the VISUM connection
format and can be read from file in VISUM by the step Connection import. Like the usual
467 PTV AG
assignment result, they are then available for all further analyses (flow bundle, network
graphics, and lists).
Variants of assignment results can be filed on hard disk and read from file, if necessary, for
analyses. It is no longer necessary to use several version files. For the export of paths
hardly any additional computing time has to be assumed. Measurements have revealed an
increase of 3 to 5 percent.
Alternatives to the connection search
Symmetrically, instead of the Search, path files can be imported, saving a lot of time in most
networks.
Alternatively, a search can equally be replaced by using paths resulting from a previous
assignment, which is also saving a lot of time. This method is similar to the option Use current
assignment result as initial solution known from PrT assignments (see User Manual, Chpt.
5.6.2.2, page 891). However, unlike PrT, the path search may be dropped completely for public
transport.
These options allow the following applications for example.
Paths from external sources can be taken as inputs to the VISUM assignment. This allows
a user-defined search without having to abandon the other advantages offered by the
VISUM assignment.
Replacing a connection search by a pre-calculated path file or by paths taken from an
already existing assignment again saves time. Since generally the search parameters are
not modified between two assignments, redundant repetitions of the same calculation can
be omitted.
In almost all networks, a search takes up most of the time within the assignment. Taking
existing paths as a basis may reduce the search time required to approximately one tenth.
Illustration 157: Flow chart of a timetable-based assignment
According to illustration 157 the following is possible in VISUM.
(3)+(4)
Wege aus
Umlegung oder
aus Datei
Paths from
assignment or
from file
(2a)
(2b)
(1)
Search
Preprocessing
Assessment
Choice + path volumes
Network volumes
belastete Wege
aus Datei
Paths with volumes
from file
Wegeexport mit
Belastungen
Path export with
volumes
Wegeexport ohne
Belastungen
Path export without
volumes
468 PTV AG
1. External choice / Connection import
Connections with volumes are imported and stored like an assignment result, therefore in
form of paths and network volumes.
2. Connection export
In order to provide the external choice with data, connections can also be exported. This
can be done either with or without volumes, in one or several files, and with or without fare
points or fares.
3. Use of existing connections for the search
As alternative to the internal VISUM search already existing connections can also be taken
as a basis, i.e. on paths of a previously performed assignment. This assignment may even
belong to different demand segments than the current one. This feature is of major interest
if the search parameters have not been modified, but a choice is to be carried out with
different settings.
4. Import of connections for the search
Alternatively to the internal VISUM search connections can equally be imported at the start
of the assignment. However, contrary to item (1) no complete assignment result will be
produced based on the imported paths, the paths will only be used as input for the
assignment to be calculated.
6.10.7.1 Steps of the timetable-based assignment
When importing or exporting connections, the following has to be noted.
Due to the amount of data the steps are performed by OD pair. Only the connection search
is run per origin zone.
All connection attributes which are relevant for the choice at least depend on the demand
segment, the impedance of a connection additionally from the time interval. Adding up all
volumes of a connection over all time intervals, the total volume per OD pair can be
determined.
Optionally, the paths can be stored. The paths can be saved as routes or as connections.
The skim matrix can only be calculated if detailed connection skims are available, i.e. it is
only possible if the connection choice is performed within VISUM.
Import and export of connections
After the pre-selection, connections are available per OD pair. The quality skims for these
connections will be calculated later.
This is therefore the right time to export (2) or to import (4) all determined connections per
OD pair, if volumes do not have to be known.
If connections including volumes have to be exported, this needs to be done after the
internal assessment.
External choice
Due to lacking asynchronous control the external choice cannot be fitted in between VISUM
connection search and path storage. In fact, the following three steps are necessary.
469 PTV AG
VISUM Method
Timetable-based assignment with Connection export option(see User Manual, Chpt.
6.2.4.8, page 984). An assignment does not have to be calculated at the same time.
External choice
VISUM Method
Connection import (see User Manual, Chpt. 13.3, page 1406)
6.10.7.2 Implementation
File format for connection import and export
For the importation and exportation of paths a uniform file format is used. Due to the huge
amount of data, only a binary format has been used so far. In the medium term, a text format
will also be realized.
Since the assignment is carried out per OD pair, the connection files have to be structured in
the same way, that is, all connections of the same relation have to be read or written in one go,
ordered according to zone numbers.
During a connection import to multiple files, the data is distributed to several files.
Data format of the connection file
A connection file contains the following data in the following order.
1. A version number is written, which later allows the format to be modified.
2. Number of path files so that VISUM identifies when re-importing whether or which
additional files need to be searched for.
3. Indication on whether the file contains the number of fare points at the path leg.
4. Indication on whether the file contains the connector nodes.
5. Level of fare data contained in the file (0 = no fares).
6. Codes of the assigned demand segments, for future allocation of volumes when re-reading
them. If connections are exported without volumes, no demand segments are stored, which
means the number of demand segments is = 0. Thus, it can be recognized whether a file
includes volumes or not.
7. The keys of all public transport systems and time profiles of the network in assorted order.
Thus, later (generally numerous) references to public transport systems of time profiles no
longer require the output of the complete key string, but the index can be used instead.
Important is the congruence of public transport systems and time profiles in the network
and the connection file. The term PuT transport systems comprises all PuT-Line TSys,
PuT-Walk TSys and PuT-Aux TSys.
8. All connections are stored separately per OD pair.
Each connection consists of several PuT path legs.
Pure walk link connections only have zero PuT path legs.
A path leg is either of type PuT-Line or PuT-Aux. In the first case it connects time profile
items, in the second case nodes.
Example: Connection file in binary data format
Bi nar yVer si onNo ( 4 byt e- i nt eger )
Number Of Fi l es ( 4 byt e- i nt eger )
Cont ai nsFar ePoi nt s ( 1 byt e- i nt eger )
Level Of Far eI nf or mat i on ( 1 byt e- i nt eger ) / / val ue i n {0, 1, 2}
470 PTV AG
Cont ai nsConnect or Nodes ( 1 byt e- i nt eger )
NumDemandSegment s ( 4 byt e- i nt eger )
f or each cont ai ned DemandSegment i n key or der :
{
DemandSegment . Code ( st r i ng)
}
NumPuTTSys ( 4 byt e- i nt eger )
f or each cont ai ned PuTTSys i n key or der :
{
TSys. Code ( st r i ng)
}
NumTi mePr of i l es ( 4 byt e- i nt eger )
f or each cont ai ned Ti mePr of i l e i n key or der :
{
Li ne. Name ( st r i ng)
Li neRout e. Name ( st r i ng)
Di r ect i on. Code ( st r i ng)
Ti mePr of i l e. Name ( st r i ng)
}
f or each cont ai ned OD r el at i on i n key or der :
{
Sour ceZoneNo ( 4 byt e- i nt eger )
Dest ZoneNo ( 4 byt e- i nt eger )
f or each cont ai ned Connect i on:
{
Connect i onDepar t ur eTi me ( 4 byt e- i nt eger )
NumLegs ( 1 byt e- i nt eger )
f or each cont ai ned Connect i onLeg i n l ogi cal or der :
{
Depar t ur eTi me ( 4 byt e- i nt eger )
LegI sPuTLi ne ( 1 byt e- i nt eger )
i f LegI sPuTLi ne
{
Ti mePr of i l eI ndex ( see above) ( 4 byt e- i nt eger )
Fr omTi mePr of i l eI t em. I ndex ( 2 byt e- i nt eger )
ToTi mePr of i l eI t em. I ndex ( 2 byt e- i nt eger )
}
el se / / 2nd case, l eg i s of t ype PuTAux
{
TSysI ndex ( see above) ( 4 byt e- i nt eger )
Fr omNodeNo ( 4 byt e- i nt eger )
ToNodeNo ( 4 byt e- i nt eger )
}
i f Cont ai nsFar ePoi nt s ( 4 byt e- i nt eger )
{
NumFar ePoi nt s ( 4 byt e- i nt eger )
}
i f Level Of Far eI nf or mat i on = 2
{
LegFar e ( 8 byt e- r eal )
}
}
f or each cont ai ned DemandSegment i n key or der :
{
Vol ume ( 8 byt e- doubl e)
}
i f Level Of Far eI nf or mat i on = 1
{
Connect i onFar e ( 8 byt e- r eal )
}
i f Cont ai nsConnect or Nodes
{
Fr omNodeNo ( 4 byt e- i nt eger )
ToNodeNo ( 4 byt e- i nt eger )
}
}
471 PTV AG
- 1 ( 4 byt e- i nt eger )
}
- 1
With regard to semantics the following has to be taken into account.
If transfer walk links are used between two PuT path legs, these are not contained in the
file. They result from the beginning and end of the path (zone or stop area) and the TSysSet
of the assignment.
In contrast to the internal connection search it will not be checked whether the PuT vehicle
journey sections used in the connections read from file are active.
With regard to the exact format the following has to be considered.
The Intel order ("Little Endian") has to be kept.
There is no alignment, which means 4+1+2 bytes are actually exported as 7 bytes.
Strings are written as follows.
Length as 2-byte integer
Signs as sequence of characters (each 1 byte)
Consistency check during the data import
If a data conflict is detected, the procedure will be aborted. Conflicts can occur in the following
cases.
Unknown keys in the network
DSegCode
Combined time profile ID
Zone number
Time profile item index
Different sets of transport systems or time profiles in network and connection file
Improper time profiles (TSys not in TSysSet of the assigned mode)
Invalid departure times (no trip on time profile at indicated time(s) or only outside the
assignment time interval plus extension)
Invalid transitions (transfer walk time exceeds the difference between departure and last
arrival)
Negative volumes
Realization (1) External choice / Connection import
The external choice allows the user to assign volumes to a given number of connections
according to variable rules and to import them again into VISUM so that an assignment result
of usual structure is available (see User Manual, Chpt. 13.3, page 1406).
In the chart in illustration 157 this is scheduled above the network loading. The paths contained
in the connection file are converted into the internal data structure and therefore no longer
differ from paths calculated within VISUM. Thus, connection import has the same effect as an
assignment.
This means the following.
Existing assignments for those demand segments whose volumes are contained in the
connection file are deleted.
472 PTV AG
A joint path container for the demand segments given by the connection file is created.
On the basis of the procedure parameters selected for path storage (as connections / as
routes / do not save), paths are generated in VISUM from the imported connections (see
User Manual, Chpt. 6.1.1.2, page 944).
At the same time the path volumes read in are transferred into network volumes.
If according to the currently set assignment parameters the volume of a demand segment
contained in the file is to be stored for another DSeg, this parameter is set back to the
default value (storing for the DSeg itself), i.e. the settings of the connection file overwrite
the VISUM settings.
The current setting of the procedure parameter Number of decimal places is set to the
value specified in the file (see User Manual, Chpt. 6.1.1.1, page 943).
Realization (2) Connection export
Connection export aims at providing data for external tools to calculate the connection choice
(1) independently from VISUM. If the volumes are considered, the export can also serve the
purpose of saving complex assignment results in a file in order to load them into the storage, if
necessary (see User Manual, Chpt. 6.2.4.8, page 984).
Connections can be exported with or without volumes.
With volumes
If, together with the connections, the volumes calculated in VISUM are to be exported as
well, the export may only be done after the choice has been completed. When exporting
volumes, only demand segments with volumes that shall not be stored onto other demand
segments are considered.
Without volumes
For an external choice, the connections are exported directly after the search. When
exporting connections without volumes, users can now specify the following for the search
of connections and the export of the result.
Either on all relations
Or only on relations with demand > 0 (as before VISUM 9.3)
Option Regard all relations is only available when selecting Export of paths without
volumes. Otherwise the option is disabled.
If the option is checked, a connection search is run for all relations. More paths are
exported accordingly. This option should be used if it is unknown which relations have an
existing demand, yet the user would like to save the paths at an early stage (e.g. in the
context of a skim matrix calculation).
Otherwise the logic used so far applies, meaning that no connection needs to be built on
relations with no demand and, in the case of origin zones without any demand, a search
can remain undone altogether, which has an advantageous effect on the calculating time
and the size of the connection file. The option is useful, if the result of the connection
search is to be saved to a file merely as a base for later assignment and if the OD matrix
does not need to be edited in the meantime.
The exported connection file can - independently of the options above also contain the
following:
Fare points of the path leg (cannot be imported) and/or
Fares per path or path leg (can be imported)
473 PTV AG
For fare calculations in the context of the external choice, option with fare points has to be
enabled since the fare is based on the number of fare points per path leg of the connection.
Extended binary format of the exported file *.con
Under ContainsFarePoints you can find the information, if the file contains fare points (1
byte required). If the file contains fare points, the number of fare points (4-byte integer) is
also exported for each path leg (thus in the inner ConnectionLeg loop) together with the
previous indices for time profile, start item and end item.
Please note, that this information is not read from file. It is only an output value which
supplies the external choice.
Optionally, the connection export can also include the fares.
The program thus offers the path leg attribute Fare which, just like the fare of paths (i.e. per
connection), is calculated with the assignment and includes the proportional fare of the
path leg.
Depending on the setting, fares are not saved to the connection file or either on path level
or on path leg level. Only fares of those paths that need to be exported anyway are saved.
The amount of exported paths does therefore not depend on the fares of the individual
paths.
For the export of fares in the *.con file, the current setting for the save fares option (see
User Manual, Chpt. 6.1.1, page 943) is not relevant. If currently Do not save is set for this
option, the connection fares will indeed be calculated during assignment, but they will not
be stored with the paths. The calculation itself is performed as described for the operational
indicators.
Fares per path or path leg can be imported and exported with the connection file (see User
Manual, Chpt. 13.3.1, page 1406).
It is possible, but not necessary, to deactivate the option Calculate assignment for the
connection export. If deactivated, no paths or volumes are stored (as is the case for a pure
indicator calculation). Instead, existing assignments for the selected demand segments will
then be maintained.
For connection export without volumes the following assignment parameters are relevant.
Origin zone interval
Assignment time interval with extension
All search parameters
All pre-selection parameters
All other parameters are only effective if an assignment is actually performed, a skim matrix
stored or a connection export carried out.
During the export, connections can be saved to one file for all OD pairs or to several files. This
guarantees that large files with a great number of paths (size > 4GB) can be read in again.
Alternatives to the internal connection search (Implementation (3) / (4))
At the beginning of the calculation, predefined connections can be added instead of calculating
a complete connection search. Within the framework of the choice (see "Connection Choice"
on page 458) added connections will be dealt with in the same way as those determined by the
internal search.
There are two alternatives to connection search.
474 PTV AG
Usage of available paths resulting from a previous assignment (3)
Reading in a set of connections from file (4)
These options have several advantages.
Reduced computing time for the assignment
Reduced storage capacity required during the assignment
Use of external search algorithms
Realization (3) Use of existing connections for the search
In this option the user indicates a demand segment for which an assignment has already been
performed.
If this assignment matches the assignment procedure currently to be calculated, the paths can
be re-used. The assignment and the procedure currently to be calculated fit, if the following
requirements have been fulfilled.
The existing assignment must fulfill the following requirements.
It has to be timetable-based.
Furthermore, it has to have been calculated with a connection-based path storage.
Attention, this is not the standard setting (see User Manual, Chpt. 6.1.1.2, page 944).
The selected demand segment has to fulfill the following requirements.
The DSeg has to belong to the same mode as the DSegs currently to be assigned.
The DSeg can (but does not have to) belong to the DSegs currently to be assigned. In
each case, the demand segments to be assigned are allocated to the path container of
the selected demand segment, this means paths will not be duplicated, but the existing
ones are used by several demand segments.
Realization (4) Import of connections for the search
In this option the user indicates a connection file, as also is used for the Connection import
procedure (see User Manual, Chpt. 13.3.1, page 1406). In this context, however, the volumes
stored in the file are ignored, only the paths are read in.
During the import, the level of the contained fare information is read from the header of the
*.con file (see "Implementation" on page 469). Please note, that the current option setting Save
imported fare data (see User Manual, Chpt. 6.1.1.2, page 944) determines whether and how
these fares are taken on (see "Implementation" on page 469). Therefore, the performance is
identical to the one affected by setting Save paths during the connection import. If the file
contains fares per path or path leg, the required attributes are loaded in the same way as
during assignment with an appropriately set Save fares value.
By combining Connection import (1) and use of existing paths (3) the same reaction can be
produced. However, it requires more storage capacity and the operation is more complicated.
If after the importation no assignment is to be calculated, but a skim matrix has to be
determined, a different proceeding would be conceivable. The connections could be imported
including volumes which are directly used as weights for the skim calculation. This has not
been planned yet, but it is assumed that such an import will be performed only in connection
with a real assignment (where skim matrices can be calculated, too).
475 PTV AG
Chapter 6.11: Assignment analysis PuT
6.11 Assignment analysis PuT
Assignment analysis is used for calculating the correlation (Goodness-of-Fit Report) between
calculated and observed attribute values of a selected network object type.
The calculated value is derived from the assignment or the network model.
The observed value may be count data or measured data.
Here are some examples:
Journey time comparisons between PrT and PuT
Journey time comparisons of different scenarios
Calculated and counted volumes (links, turns or main turns)
Calculated and measured speeds
Any numeric input and output attributes of the following network objects can be selected:
Links
Nodes
Turns
Main nodes
Main turns
Lines
Line routes
Screenlines
Time profiles
Paths
Prerequisite is, that the observed values must be >0 for the selected network object type.
You can select which objects you want to include in the assignment analysis. There are three
possibilities:
All objects of the selected network object type
Only active objects
Only objects with observed value > 0
For the assignment analysis, as an option, you can consider user-defined tolerances for user-
defined value ranges of the calculated attribute.
The quality of the correlation can be determined and issued in two ways:
in groups (for each value of the classification attribute)
collectively for all included network objects
For the output, the data model of the network object types above has been supplemented with
the calculated attribute Assignment deviation (AssignDev) of type real. Alike all other
VISUM attributes, the attribute can be graphically displayed and issued in lists of the respective
network object.
In addition, VISUM calculates various indicators (per group or collectively) that can be issued
in a list or in a chart.
476 PTV AG
Table 171 shows the calculation rules for the output attributes of the assignment analysis. The
following applies to the formulas:
Note: An assignment result is no longer necessary in order to calculate the correlation
coefficient.
Z Observation (count or measurement)
U Calculation (assignment or network model)
N Number objects with an observed value > 0
AbsRMSE
Abs RMSE
Absolute root of mean square deviation
Significant differences between counted and modeled values have a higher
impact according to
Intercept
Intercept
Coefficient b in linear regression
Cf. Excel function: Linear Regression (y = ax + b)
Percent acc GEH
Percent with acc GEH
Percentage objects with acceptable GEH value (per network object)
Percent avg rel E
Percent with avg rel error
Percentage objects within tolerance
N Obs
Number of observations
Number of observations per class (objects with observed value > 0)
N class
Number in class
Total number (=observed + not observed) objects per class
ClassValue Value of classification attribute (or blank, if not classified)
Corr Correlation coefficient (cf. Excel function Pearson)
Notes
The value range lies between -1 and 1, where the following applies:
-1 = observation opposed to modeling
0 = no correlation (at random)
+1 = very good correlation
The ratio observed/modeled value should be as close to 1 as possible.
In case of only 2 values > 0, the correlation coefficient is -1 or 1.
From the value of the correlation coefficient, one cannot determine whether all
observed values are higher (or lower) than the calculated values or upward
and downward deviations exist.
( ) ( ) 2 1
N
1 i
N
2
i
U
i
Z
=
=

( )
( )
( ) 2
i
U
i
Z
2
i
U
i
Z
i GEH
+
=
abs Z
i
U
i
( )
U
i
------------------------------ Tolerance U ( )
477 PTV AG
Chapter 6.12: PuT Passenger surveys
6.12 PuT Passenger surveys
Passenger sample surveys - interviews and counts - are essential for public transport supply
planning. Usually the passengers route within the PuT line network is not described
completely by interview data. This applies especially to passengers who have to transfer
several times or those who need to walk for transfers.
Survey personnel usually count the passengers boarding the surveyed line at the boarding
stop and ask for the following details of the trip.
Boarding stop of passenger trip where passenger enters the survey line, which means
where the passenger is interviewed by the survey personnel,
Alighting stop of passenger trip where passenger will leave the survey line,
Origin and destination of the passenger trip.
After reading passenger data from file, it has to be verified and completed, if necessary. Also
the time of departure from either the boarding stop or the origin terminal of the survey line have
to be recorded in a questionnaire.
The VISUM add-on Passenger Onboard Survey contains the following basic functions.
Read survey data
MeanAbsE Mean absolute error
Mean deviation of absolute values(
a
)
(Difference between observed and modeled value)
MeanObs
Mean observed value
MeanRelE Mean relative error
Mean deviation of absolute values in % (
p
) according to
R2
Coefficient of determination r
2

Cf. Excel function RSQ
RelRMSE Relative root of mean square deviation
StdDev Standard deviation
Slope Coefficient a in linear regression
Cf. Excel, Linear Regression (y = ax + b)
( ) ( )
=
i
U
i
Z Abs
N
1
a
i
Z
N
1
( )
( )

=
i
Z
i
U
i
Z Abs
p
( )
( )
N
i
Z
1 N
2
i
U
i
Z
478 PTV AG
Loading data from file and conversion of data records into PuT paths (see User Manual,
Chpt. 6.12.3, page 481).
Plausibilization of survey data
Verification and completion of the survey data records which contain the basic passenger
trip data (see User Manual, Chpt. 6.12.4, page 481).
Direct assignment
Assignment of the survey data records (calculating network volumes from path
volumes),optionally OD matrices and skim matrices can be generated (see User Manual,
Chpt. 6.12.5, page 487).
After direct assignment of the survey data, the full range of the VISUM functionality for analysis
and display of results is available, e.g. flow bundle display (see "Interactive analyses" on
page 655) or PuT operating indicators (see "PuT Operating Indicators" on page 568).
6.12.1 Basic data of a passenger trip
Note: From each survey data record (which means per questionnaire or per ticket,
respectively), a passenger trip is generated and stored as PuT path.
Note: Subsequently, indicator data on path level (by survey data record) is automatically
provided in the PuT paths list.
Survey line Designation of the line, where the passenger is encountered
Origin terminal
Line i
Origin terminal
Line j
Origin terminal
Line k
Dest. terminal
Line i
Dest. terminal
Line j
Dest. terminal
Line k
DestStop
OriginStop
2nd Transfer
1st Transfer
Preceding line Survey line Succeeding line
AlightStop BoardStop
Origin / Destination of a line
Route of passenger trip
Passengers origin, boarding, transfer,
alighting or destination stop
479 PTV AG
Standard questionnaire
Illustration 158: Standard questionnaire
The replies obtained in a passenger survey are noted down in questionnaires. Such a
questionnaire form usually consists of parts.
Features which identify the questionnaire are entered in the header, such as the
interviewer's number, vehicle class and service trip number.
Preceding/Succeeding Path legs traveled by passenger before or after the survey line
A path leg is the transfer-free part of a passenger trip on a line, from boarding
to alighting (number of path legs = number of transfers + 1)
Origin terminal First stop of a service trip
Destination terminal Last stop of a service trip
OrigStop Starting stop (origin) of a passenger trip: first boarding stop entering a PuT line
per PuT path
DestStop Destination stop of a passenger trip: last alighting stop leaving a PuT line per
PuT path
BoardStop Boarding stop of the survey line: stop at which the passenger enters the survey
line
AlightStop Alighting stop of the survey line: stop at which the passenger leaves the survey
line
Questionnaire
Route
Ticket
Line:
Orig.Term:
Departure:
Preced. 2:
Preced. 1:
Boarding:
Alighting:
Suceed. 1:
Suceed. 2:
One-Way
Season
Group
Number of Persons:
42
20
30
Y town
Station
B village
Bus 1
A village
6:10
1
480 PTV AG
In the main section, codes for the boarding and alighting stops of the survey line are
entered, plus information on any preceding or succeeding lines.
illustration 158 displays a schematic example for a questionnaire. With this questionnaire, up
to 5 path legs (2 preceding legs + survey line + 2 succeeding legs) can be recorded.
6.12.2 Passenger onboard survey: Basic approach
The general procedure for the PuT passenger onboard survey is as follows. illustration 159
illustrates this procedure schematically.
1. VISUM first reads from a text file a set of survey records which closely resemble the
information in the PuT Path Legs list. For each surveyed trip, the following information is
supplied:
Vehicle journey, boarding and alighting stop point for the surveyed leg of the trip
Origin and destination of the complete trip
Information on the legs taken between origin stop and surveyed boarding stop and
between surveyed alighting stop and destination stop (if present).
2. The second operation tries to complete each survey record by filling in plausible values for
all missing fields.
Numerous plausibility checks are carried out on the survey data, and the user can
specify rules for substituting by plausible values (for example, for the lines or the
departure times of the services), if the stated values do not form part of a valid
connection.
A comprehensive log file tags each survey record with a status describing which
substitutions were performed and how reliable the resulting information is.
A new version of the survey file is written which contains all the additional information
that could be determined automatically.
Users can review the survey records which are flagged as inconsistent and decide
whether to discard or to manually correct them.
The operation Plausibilization of survey records can then be repeated.
3. As step three, survey data that succeeded during plausibilization are directly assigned to
the VISUM network.
Volumes of connections, all network object volumes and related indicators are set.
Furthermore a demand matrix can be created containing the surveyed trips.
PuT skim matrices of the connections can be created.
Any of the post-assignment analysis tools can then be applied to the assignment result
generated from survey data.
481 PTV AG
Illustration 159: Processing of PuT passenger surveys
6.12.3 Read survey data
This method loads survey data records from text files (one per PuT demand segment) into
VISUM for future plausibilization. Since VISUM stores survey data records as PuT paths, the
data can be accessed via listings as well as via COM interface or flow bundle analysis and
other VISUM functionalities provided for PuT paths (see User Manual, Chpt. 6.12.3, page 481).
6.12.4 Plausibilization of survey data
For plausibility purposes the correctness of the path stated by the passenger is verified for
each survey record. By comparing each survey record with the timetable information of the
VISUM network model it is possible to identify and correct survey records which state an
incorrect path. Incorrect lines or line routes or time profiles are replaced by correct lines or line
routes or time profiles. Furthermore, additional data is added to each data record, such as
times of departure and of arrival, travel time and trip distance, used lines and walk links.
Note: The same functionality can be applied to data extracted from e-ticketing applications, if
the data contain at least check-in information per leg with line route, stop point, and departure
time. In this case, a path leg needs to be marked as surveyed path leg.
Survey
Records
file
Import
survey
records
Incomplete
survey records
in memory
Check and
complete
survey
records
Complete
survey records
in memory
Direct
Assignment
Assi gnment
result
in memory
any post-assignment
anal ysis
Survey
Records
file
Log
fil e
The user checks the survey data
records that are not plausible and
discards or corrects them manually.
Subsequently, the plausibilization can
be repeated.
482 PTV AG
Plausibilization: Basic approach
As a rule, the plausibilization includes the following steps.
1. Validity check of the survey path leg (illustration 160)
2. Validity check of the preceding section (illustration 161)
3. Validity check of succeeding section
For each of these steps, the validity check can be run several times, in order to check the
survey data successively with hard-to-meet criteria, which become easier and easier with each
run.
Note: The boarding and alighting stops stated in the interview data records of the surveyed
line must exist in the checked network. If this is not the case, the record in question is ignored.
If one of these stops is deleted after reading survey data from file, all paths from/to these
stops will get lost.
Note: In single-row data records, the preceding section as well as the succeeding section
may consist of one or two path legs each (see User Manual, Chpt. 6.3.1.1, page 987).
Inner path leg leading from PreStop to BoardStop and from AlightStop to SucStop
respectively.
Outer path leg leading from OrigStop to PreStop and from SucStop to DestStop,
respectively.
In multi-row data records, the previous section as well as the succeeding section may consist
of any number of path legs (see User Manual, Chpt. 6.3.1.2, page 988).
483 PTV AG
Validity check of the survey path leg
Illustration 160: Validity check of the survey path leg
* In case of multiple vehicle journeys, the one with the minimum sum of run time and wait
time is chosen.
NO NO NO
not
plausible
YES YES
Check for a vehicle journey from
BoardStop to AlightStop in surveyed
time profile (or line route or line) with
departure within the valid range.*
Other criteria for
direct validity check?
YES YES
YES YES
Path leg of survey line
from data record
plausible
NO NO NO
NO NO NO
nein nein nein
Connection search permitted? Check for (in)direct connection
from BoardStop to AlightStop
with departure within the valid range.
E1 E1
E2 E2
E3 E3
E5 E5
State of plausi bilization: Survey line
E1 E1 E2 E2 E3 E3 E5 E5
E7 E7 E8 E8 E9 E9
plausible
not plausible
Check for a vehicle journey from
BoardStop to AlightStop in all of the
time profiles of the survey line or in all
time profiles of the network.*
YES YES
YES YES
NO NO NO E7 E7
E8 E8
E9 E9
Cf. list of survey path leg states 0..9 below
484 PTV AG
Validity check of prec. section (Example with 1 or 2 prec. path legs)
Illustration 161: Validity check of the preceding section
* In case of multiple vehicle journeys, the one with the minimum sum of run time and wait
time is chosen.
Validity check of succeeding section
The validity check of the succeeding path leg(s) is performed accordingly (illustration 161).
Status IDs for the plausibilization quality
In a result file and also in lists (PuT paths and PuT path legs), a status ID (range 0...9)
describes the quality determined by validity check and plausibilization for each survey record:
for the surveyed path leg E in Table 172,
for the preceding section V in Table 173,
Find vehicle journey from PreStop to BoardStop in
preceding time profile (or line route or line) matching
the survey lines departure time from the BoardStop.*
Check inner path leg
PreStop - BoardStop, regard given
arrival time at BoardStop
Survey line is plausible
(i.e. departure time
and preceding stops
and further information
available)
NO NO NO
Plausibilization state of preceding path legs:
V1 V1 V2 V2 V3 V3 V4 V4
V9 V9
plausible
not plausible
V5 V5 V6 V6
YES YES
V1 V1
Other criteria
for direct validity check?
Find vehicle journey from PreStop to
BoardStop in one of the time profiles of the
preceding line or in all TPs of the network.*
V2 V2
V3 V3
Connection search permitted
for a single path leg?
Find (in)direct connection from PreStop to
BoardStop matching the survey lines
departure from the BoardStop.
NO NO NO
Find another
preceding path leg
V5 V5
YES YES
NO NO NO V9 V9
YES YES
Find another
preceding path leg
YES YES
Check outer path leg
OrigStop - PreStop,
regard given arrival time at PreStop
Find vehicle journey from OrigStop to PreStop
on preceding time profile (or line route or line)
matching the departure time of the
inner path leg from the PreStop.*
plausible
YES YES YES
not
plausible
NO NO NO
ViT ViT
ViT = Status of the inner path leg
Is option
Connection search
active for remaining
preceding section?
NO NO
Find an (in)direct connection
from OrigStop to BoardStop
with arrival at BoardStop
matching the survey lines
departure time from the
BoardStop.
V9 V9
V9 V9
Find (in)direct connection from OrigStop
to PreStop with arrival at PreStop
matching the inner path legs departure
time from the PreStop.
Is option Direct
connection active?
Find direct connection from
OrigStop to BoardStop with Journey
time Factor + constant < Journey time
of multi-part preceding section.
Vm = Max (Status of inner path leg / Status of outer path leg)
NO NO NO
NO NO YES YES YES
Find vehicle journey from OrigStop to PreStop
in one of the TPs of the preceding line or in all
TPs of the network matching the inner path
legs departure time from the PreStop.*
NO NO NO
Connection search permitted
for a single path leg?
NO NO
V9 V9
YES YES
YES YES YES
Is the found connection
an indirect one?
YES YES
NO NO NO
NO NO
ViT ViT
Vm Vm
YES YES
V4 V4
NO NO
NO NO
Vm Vm
Vm Vm
YES YES
V6 V6 YES YES
YES YES
YES YES YES
YES YES
Cf. list of preceding/succeeding path leg states 0..9 below
485 PTV AG
for the succeeding section N in Table 174,
for the entire survey data record G in Table 175.
Status indicators for the surveyed path leg (E)
0 Not yet checked
Plausible
1 A vehicle journey could be found in the surveyed time profile (or surveyed line route or line,
depends on preciseness of input data), which connects boarding stop and alighting stop of the
surveyed path leg and starts within the time tolerance interval defined for the time of departure
from the boarding stop.
2 A vehicle journey could be found in another time profile (or line route) of the surveyed line,
which connects boarding stop and alighting stop of the surveyed path leg and starts within the
time tolerance interval defined for the time of departure from the boarding stop.
3 A vehicle journey could be found in a time profile (or line route) of another line, which connects
boarding stop and alighting stop of the surveyed path leg and starts within the time tolerance
interval defined for the time of departure from the boarding stop.
5 For the surveyed path leg, an indirect connection could be found by timetable-based search
(shortest path search) which departs from the boarding stop within the tolerance interval
defined for the departure time from this stop and includes at least one transfer (and walk links,
if applicable).
Not plausible
7 Implausible, because none of the line routes (which are valid due to current parameter settings)
connects boarding stop and alighting stop and connection search is not permitted either.
8 Implausible, because the time profiles of the line routes (which are valid due to current
parameter settings) connecting boarding and alighting stop do not include a departure within
the time tolerance interval defined for the time of departure from the boarding stop and
connection search is not permitted either.
9 Implausible, because no connection from boarding to alighting stop starting in the given time
frame could be found during connection search calculation.
Table 172: Status indicators for the surveyed path leg
Status indicators for the preceding section (V)
0 Does not exist
Plausible
1 A vehicle journey could be found in the preceding time profile (or preceding line route or line,
depends on preciseness of input data), which meets the condition defined for the permitted
time span.
2 A vehicle journey could be found in another time profile (or line route) of the preceding line,
which meets the condition defined for the permitted time span.
3 A vehicle journey could be found in a time profile (or line route) of another line, which meets the
condition defined for the permitted time span.
4 A direct vehicle journey from OriginStop to BoardStop with a shorter journey time (Factor
Journey time of Direct connection + constant < Journey time of preceding section) compared to
the plausible (multi-part) preceding section could be found and is used instead.
Table 173: Status indicators for the preceding section
486 PTV AG
5 Replacing at least one of the preceding path legs by an indirect connection which was found by
timetable-based connection search (incl. transfer(s) and walk link(s), if applicable).
6 Replacing the implausible (multi-part) preceding section from OriginStop to BoardStop by a
connection with an arrival time matching the departure time of the survey line from the
BoardStop.
Not plausible
9 Implausible, because no path leg (or sequence of path legs) could be found meeting the given
validity check criteria.
Status indicators for the succeeding section (N)
0 Does not exist
Plausible
1 A vehicle journey could be found in the succeeding time profile (or succeeding line route or
line, depends on preciseness of input data), which meets the condition defined for the
permitted time span.
2 A vehicle journey could be found in another time profile (or line route) of the succeeding line,
which meets the condition defined for the permitted time span.
3 A vehicle journey could be found in a time profile (or line route) of another line, which meets
the condition defined for the permitted time span.
4 A direct vehicle journey from AlightStop to DestStop with a shorter journey time (Factor
Journey time of Direct connection + constant < Journey time of succeeding section) compared
to the plausible (multi-part) succeeding section could be found and is used instead.
5 Replacing at least one of the succeeding path legs by an indirect connection which was found
by timetable-based connection search (incl. transfer(s) and walk link(s), if applicable).
6 Replacing the implausible (multi-part) succeeding section from AlightStop to DestStop by a
connection with a departure time matching the arrival time of the survey line at the AlightStop.
Not plausible
9 Implausible, because no path leg (or sequence of path legs) could be found meeting the given
validity check criteria.
Table 174: Status indicators for the succeeding section
Status indicators for the entire survey data record (G)
0 Not processed
Plausible
1 All of the sections (preceding leg(s), succeeding leg(s) and/or survey leg) are plausible.
Not plausible
9 Implausible because of one (or more) implausible sections (preceding leg(s), succeeding
leg(s) and/or survey leg).
Table 175: Status indicators for the entire survey data record
Status indicators for the preceding section (V)
Table 173: Status indicators for the preceding section
487 PTV AG
6.12.5 Assignment of survey data
Direct assignment means assignment of a demand segments plausible paths to the PuT line
network (see User Manual, Chpt. 6.3.4, page 1002).
Subsequently, any of the post-assignment analyses provided for public transport can be
carried out.
Volume display as bars along links (see "Tabular and graphic display" on page 679)
Flow bundle calculations (see "Flow bundles" on page 655)
Skim matrix calculation on the basis of directly assigned paths (if not already calculated at
the direct assignment),(see "PuT skims" on page 414)
Calculation of PuT operating indicators, for example for the line costing and revenue
calculation (see "PuT Operating Indicators" on page 568)
488 PTV AG
489 PTV AG
7 Operator model PuT
The PuT operator model in VISUM comprises the PuT operating indicators and the PuT line
blocking procedure.
Subjects
Application areas and scope of operations
Network objects in the operator model
Typical work flow in the PuT operator model
Line blocking
PuT fare model
PuT Operating Indicators
Calculation of the fare revenues (revenue calculation)
7.1 Application areas and scope of operations
The results of the procedures PuT operating indicators and Line blocking are saved in
attributes, which are overall designated as operating indicators. These can be divided into the
following categories:
General indicators for bundling line data (for example the number of service trips per line
route)
Indicators for the measurement of the operating performance (for example the service
kilometers to be run by an operator)
Indicators for the measurement of the transport performance (for example the passenger
hours for a service trip)
Indicators for the calculation of the operating costs (for example the stop point costs per
line). The cost model permits modeling of vehicle type-based costs as well as infrastructure
costs.
Indicators for the calculation of fare revenues (revenue calculation). Zone-based fares,
distance-based fares as well as further fare structures can be modeled for fare calculation
in VISUM.
Indicators of vehicle requirement and of line blocking
Typical application areas of the operator model are:
Assessment of the economic efficiency of an existing PuT supply and derivation of
improvement potentials
Analysis of the effects of supply changes on the economic result (cost coverage)
Comparison of costs for establishment and maintenance of PuT supply and fare revenues
Calculation of the cost coverage on different aggregation levels of the line hierarchy (for
example cost coverage per line, line route or trip)
Distribution of the fare revenues onto operators of a PuT supply
Distribution of the fare revenues onto local authorities (counties, municipalities)
490 PTV AG
Chapter 7: Operator model PuT
Performance check down to the trip and vehicle level
The second module of the operator model is line blocking. A line block contains all (see User
Manual, Chpt. 7.1, page 1019) vehicle journeys which are run successively by one vehicle
combination or by several similar vehicle combinations. The objective of line blocking is to
assign the total number of trips to vehicles, so that costs are reduced. Also line blocking
provides indicators such as empty kilometers of a line block. In the following, these are
designated as indicators of the vehicle requirement and line blocking. In most cases line
blocking is carried out prior to the calculation of PuT operating indicators in the procedure flow,
because it provides input attributes for cost analyses (determination of the number of vehicles,
which has an effect on the vehicle costs in the PuT operating indicators). The procedure PuT
interlining matrix is provided in addition to the line blocking procedure. It calculates transport
system-specific skim matrices for interlining trips between stop points of a transport system.
7.1.1 Calculation of indicators on different aggregation levels
VISUM allows indicators to be calculated in different granularity. Passenger kilometers, costs,
and revenues, for example, can be calculated for trips served by a specific line using low-floor
buses between 6 and 7 a.m. in the municipal territory. Or have the passenger kilometers
calculated for each operator in your model, to divide the fare revenues between the operators.
The indicators can be calculated as follows.
Differentiated according to territory, for example local authorities such as counties or
districts (see User Manual, Chpt. 7.3.1, page 1075)
According to operating companies
Temporal distinction through freely adjustable time intervals within a day, or if a calendar
is used within a week or a year. This is independent of the PuT operating indicators
procedure (see User Manual, Chpt. 4.2, page 823)
Differentiated according to the objects of the line hierarchy. These include main lines, lines,
line routes, line route items, time profiles, time profile items, service trips and service trip
items
There are different levels of detail for breaking down indicators to territories. To calculate
indicators on these levels of detail, apply the procedure PuT operating indicators (see User
Manual, Chpt. 7.3, page 1075). The results of the procedure can be found in the PuT Detail list.
In detail, the indicators can be calculated for territories on the following levels (this concerns
indicators from the PuT assignment as well as from the procedure PuT operating indicators
and the line blocking procedure):
Territory
Territory x Transport system
Territory x Main line
Territory x Line
Territory x Line route
Territory x Time profile
Territory x Vehicle journey
Territory x Transport system x Vehicle combination
Territory x Main line x Vehicle combination
Territory x Line x Vehicle combination
491 PTV AG
Chapter 7.1: Application areas and scope of operations
Territory x Line route x Vehicle combination
Territory x Time profile x Vehicle combination
Territory x Vehicle journey x Vehicle combination
If a VISUM model has two territories (west, east) and three transport systems (bus, tram, train),
indicators are calculated for each combination of territory and transport system on the level
territory x transport system.

7.1.2 Introductory examples for PuT indicators
For several indicators, the computation of indicator data with spatial reference to a territory,
with temporal reference to a time slice, by operator and for the elements of the line hierarchy
is described below. The examples are there to give an impression on the application
possibilities and the performance of the PuT operator model. The documentation also contains
example calculations for the individual indicators (see "Description of the PuT interlining matrix
procedure" on page 545). Which indicators are available on which evaluation levels, can be
found in the files IndicatorSource.xls and IndicatorAvailability.xls under \VISUM115\Doc\Eng.
The values were created with the example KA_dyn.ver, which is provided in your VISUM
installation, and can thus be reproduced.
7.1.2.1 Indicator data by territory
Using territory-related evaluations, you can calculate indicator data for territories which
represent fare zones, urban districts, municipalities or counties for example. The territory
polygon is decisive for the calculation; and the indicators share, which applies to the polygon
(see "Territories" on page 40) will be returned. The example network of Karlsruhe contains six
territories (illustration 162). In the example, the territories correspond to the PuT fare zones
created in the VISUM fare model. This means, that the polygons (territory boundaries) were
modeled in such a way, that they contain exactly those stops of the respective PuT fare zones.
Each PuT fare zone thus corresponds to exactly one territory and the indicators can be
calculated by fare zone. Some examples for possible territory-based analyses are introduced
below.
Territory TSys ServiceKm PassengerKm
East Bus 2,776.88 17,219.-58
East Train 1,611.57 21,094.72
East Tram 6,796.78 187,312.42
West Bus 538.57 9,671.80
West Train 323.14 5,803.08
West Tram 5,703.52 214,538.25
Table 176: Level Territory x Transport system
Note: Not every indicator is available for all aggregation levels. In the IndicatorAvailability.xls
file under \VISUM115\Doc\Eng you will find tables which will tell you on which aggregation
levels the indicators are available.
492 PTV AG
Illustration 162: Territories in the example
Using the indicators Number of stop points Total, Line network length (directed) and the
Number of service trips, information can be obtained on the line routes and the timetable of the
model for each territory. Within the territory polygon Center there are 182 stop points. The line
network length is calculated per transport system. The directed line length (the total link length
of the links traversed via line routes) of the bus network in the city center is 54 km. In the
analysis period of one day, 3154 service trips (number of service trips with at least one stop
within the territory polygon) stop in this territory. Using these indicators as a basis, the first
statements regarding the PuT connectivity of the territories can be made.

Territory Stop points total Line network length directed (Bus)
[km]
Number of service trips (AP)
Center 182 54.015 3.154
North East 53 34.993 814
South 14 8.716 350
East 73 90.188 1.776
West 157 66.749 1.779
Suburbs 96 58.474 1.888
Table 177: Indicators for line route analysis by territory
493 PTV AG
The performance indicators represent the efforts required for the PuT supply provision in
length units or in time units. The most used indicator is called service kilometers or service
miles, if applicable. These are the main drivers for costs, which arise for the operator of a line
The ratio between the service miles and the revenues, which are generated in a territory, can
provide information on how efficient the performance is in this territory. In the example, this
ratio is stored in the user-defined attribute Revenue_per_ServiceKM. For that purpose, the
value of this formula describing the ratio was stored in the user-defined attribute. In this way,
also territories can be identified, where it is also very appealing for a PuT operator, to provide
transport performance. In the outer regions of the example (suburbs), where fewer passengers
have to be transported, however, longer distances have to be covered, less revenues probably
accumulate than in the center. Such a view is useful, if no costs have been modeled in VISUM
and simply tendency statements on the cost-effectiveness in a territory are desired.
7.1.2.2 Territory-based evaluation on different aggregation levels
The indicator data can be refined even more, if the territory is evaluated on different
aggregation levels. Indicators can for example, be calculated like this for each line within a
territory.
In the field of transport performance, the indicator Passenger kilometers of a line within a
territory is often used for analyses. On attainable PuT revenues, the passenger kilometers
permit statements by trend, especially in case there are no data on the exact revenues and
these are therefore not modeled in VISUM. Table 179 shows the passenger kilometers and
the number of passenger trips (number of passengers boarding) for line 2 in the territories,
which are traversed (illustration 163). For this evaluation, the aggregation level Territory x
Line was selected (see User Manual, Chpt. 7.3, page 1075). This is how you can determine
how many passenger kilometers of the line apply to the fare zones.
Territory ServiceKm(AP) [km] Revenue length-proportional
(AP) [CU]
Revenue per ServiceKM
[CU/km]
Center 16.648 143,945.75 8.65
North East 2.918 8,674.07 2.97
South 1.379 7,416.01 5.38
East 6.615 24,371.61 3.68
West 6.328 40,159.07 6.35
Suburbs 11.191 4,736.75 0.42
Table 178: Territory-based indicator data for transport performance and revenue analysis
494 PTV AG
Illustration 163: Line 2 traverses several territories
7.1.2.3 Indicators at the line hierarchy
If you are not interested in the territory-based evaluation of indicators, you can also carry out
evaluations directly at the line hierarchy levels. For a PuT operator it is important to know for
example, what the volume/capacity ratio of the vehicles is along the course of the line routes.
Based on this, the operator can decide to lengthen or shorten a line route. Table 180 shows
the beginning and the end of the line route course of line 002 and the saturation of seats
between stops. Between Siemensallee and Lassallestrae, the average volume/capacity ratio
is only 4 %, so that shortening the line may be a possibility.
Territory Line PassengerKm(AP) [km] Passenger trips unlinked
Center 2 80.590 30.533
East 2 21.021 9.479
West 2 4.356 6.021
Table 179: Territory-based analysis on aggregation level Territory x Line
495 PTV AG
.
The service kilometers are often taken into account for the distribution of the calculated
operating costs between an infrastructural operator and the provider of the PuT supply. In this
example, Line S3 uses the infrastructure of the Deutsche Bahn (German Rail). In the Lines list,
the service kilometers can be displayed per line.
.
Index Line route
name
Direction
code
Node number Stop point name Vol/Cap ratio
Seats [%]
1 2_H > 105497581 Wolfartsweier Nord 8
2 2_H > 105224474 8
3 2_H > 105224473 8
4 2_H > 105497580 Durlach Zndhtle 10
5 2_H > 105497579 10
6 2_H > 105226816 10
7 2_H > 105226814 10
8 2_H > 105226812 10
9 2_H > 105222467 10
10 2_H > 105497578 Aue Friedhof / Steiermrker
Str.
11
... ... ... ... ... ...
106 2_H > 100521 Kussmaulstrasse 41
107 2_H > 100522 Hertzstrasse 26
108 2_H > 100523 Feierabendweg 21
109 2_H > 100524 Neureuter Strasse 9
110 2_H > 105496077 9
111 2_H > 100525 Siemensallee 4
112 2_H > 100526 Lassallestr 0
Table 180: Analysis of the Vol/Cap ratio of seats on the line route level
Line name Transport system Service kilometers [km]
R92 TRAIN 243.612
S1 TRAM 2,468.828
S11 TRAM 1,080.146
S2 TRAM 3,273.128
S3 TRAM 835.176
S31 TRAM 577.254
S4 TRAM 2,129.673
S5 TRAM 4,074.132
S8 TRAIN 53.920
Table 181: Service kilometer analysis on the level of lines
496 PTV AG
VISUM supports you when making a decision on the line bundle to be run by a bus operator
("To which operator, which of the lines are allocated?"). For each line, typical indicators such
as costs, total revenue, revenue per passenger trip, total cost coverage and cost coverage per
passenger trip are calculated. The table shows the values for the analysis horizon of one year.
Lines with a cost coverage deficit have a negative amount of coverage. In terms of balancing
the high-profit lines and low-profit lines as fair as possible, this data can be used to form line
bundles, for which PuT operators then can apply in the framework of a tender.
Line
name
Transpo
rt
system
Costs [CU] Revenue total
[CU]
Revenue
PTrip [CU]
Cost cov. total
[CU]
Cost cov. /
PTrip [CU]
Cost cov.
[%]
21 BUS 433,831.31 773,477.34 0.56 339,646.03 0.25 178.29
22 BUS 254,736.07 314,551.88 0.53 59,815.80 0.10 123.48
23 BUS 487,624.88 214,824.83 0.55 -272,800.05 -0.70 44.06
30 BUS 515,029.02 1,818.301.46 0.63 1,303.272.44 0.45 353.05
31 BUS 705,276.05 872,187.83 0.59 166,911.78 0.11 123.67
32 BUS 452,384.95 425,354.17 0.4 -27,030.78 -0.03 94.2
42 BUS 361,669.22 868,201.73 0.52 506,532.51 0.0 240.5
43 BUS 276,488.08 215,746.49 0.50 -60,741.59 -0.14 78.03
44 BUS 333,456.14 54,659.89 0.53 -278,796.26 -2.69 16.39
45 BUS 429,574.91 330,818.45 0.61 -98,756.46 -0.18 77.01
46 BUS 188,345.74 261,343.71 0.51 72,997.98 0.14 138.76
47 BUS 339,342.42 189,913.11 0.71 -149,429.31 -0.56 55.97
50 BUS 509,071.08 988,980.88 0.58 479,909.80 0.28 194.27
51 BUS 88,748.77 195,342.70 0.57 106,593.93 0.31 220.11
52 BUS 328,666.85 335,666.87 0.52 7,000.01 0.01 102.13
55 BUS 0.00 0.00 0.00 0.00 0.00 0.00
60 BUS 337,039.94 2,004,260,28 0.51 1,667,220,34 0.43 594.67
62 BUS 0.00 0.00 0.00 0.00 0.00 0.00
70 BUS 717,616.46 1,375,946,79 0.53 658,330.33 0.25 191.74
71 BUS 83,309.71 171,403.50 0.52 88,093.79 0.27 205.74
73 BUS 384,722.03 1,809,097,37 0.52 1,424,375,34 0.41 470.23
74 BUS 265,425,27 1,151,942,68 0.53 886,517.42 0.40 434.00
75 BUS 52,673.44 243,368.34 0.47 190,694.90 0.37 462.03
107 BUS 231,821.70 77,805.81 0.52 -154,015.89 -1.04 33.56
108 BUS 59,030.88 0.00 0.00 -59,030.88 0.00 0.00
123 BUS 397,079.54 40,164.47 0.99 -356,915.07 -8.76 10.11
151 BUS 216,990.34 41,625.77 25,569.00 -175,364.57 -7.16 19.18
222 BUS 244,624.05 23,291.90 2.16 -221,332.15 -20.56 9.52
Table 182: Cost and revenue computation on the level of lines
497 PTV AG
7.1.2.4 Evaluation of indicators on the operator level
Splitting up the revenues from fares to various operators of a transport association often
regards the service kilometers or the seat kilometers as a basis. VISUM returns this data by
operator. For the three operators in the Karlsruhe example, the following values apply.
:
7.1.2.5 Indicator data by time slice
If you are working with analysis time intervals (see User Manual, Chpt. 4.2, page 823), you can
evaluate most indicators broken down in time slices (see "PuT Operating Indicators" on
page 568). This means, that the share of an indicator value which falls in a time interval, is
calculated. In the example KA_dyn.ver, this is used to determine the service kilometers for 1-
hour-intervals. In this way, the bus operator can determine operational performance peaks and
has an indicator for the evaluation, how evenly the vehicle fleet is utilized in the course of the
day. The example shows time intervals of one hour from 5:00 a.m. to 10:00 p.m. For the bus
operator, the operator-related evaluation via all time intervals returns the following service
kilometer values.
551 BUS 142,190.73 306,929.17 0.59 164,738.44 0.32 215.86
Operator name Service kilometers [km] Seat kilometers [km]
TOK Tram Operator 12,71 1,092.238
DB German Rail 23,906 2,165.751
KBB Bus Operator 9,096 454,811
Table 183: Evaluation of transport performance indicators on the level of operators
Operator name KBB Bus Operator
ServiceKm (05:00) 227.0
ServiceKm (06:00) 622.2
ServiceKm (07:00) 689.9
ServiceKm (08:00) 602.4
ServiceKm (09:00) 487.2
ServiceKm (10:00) 443.0
ServiceKm (11:00) 461.7
ServiceKm (12:00) 537.2
ServiceKm (13:00) 604.5
ServiceKm (14:00) 541.9
ServiceKm (15:00) 608.7
Table 184: Evaluation of service kilometers per time interval for the bus operator
Line
name
Transpo
rt
system
Costs [CU] Revenue total
[CU]
Revenue
PTrip [CU]
Cost cov. total
[CU]
Cost cov. /
PTrip [CU]
Cost cov.
[%]
Table 182: Cost and revenue computation on the level of lines
498 PTV AG
If the operator additionally compares the passenger kilometers, the statements by trend can be
derived, for example the efficiency level by time interval. The time intervals 9 to 12 p.m. and
after 6 p.m. show very low values for this indicator. Thus, in opposition to a relatively high
transport supply performance (ServiceKm) there is a relatively low passenger demand.
.
7.2 Network objects in the operator model
In connection with the operator model, the following network objects are of particular
importance: operator, vehicle combination and vehicle unit. Correlations among these network
objects and their relations to other network objects are illustrated by illustration 164.
ServiceKm (16:00) 710.2
ServiceKm (17:00) 695.7
ServiceKm (18:00) 626.8
ServiceKm (19:00) 406.1
ServiceKm (20:00) 263.1
ServiceKm (21:00) 203.1
Time interval Service kilometers [km] Passenger kilometers
[km]
05:00 227.0 3,101.9 13.7
06:00 622.2 14,034.9 22.6
07:00 689.9 24,411.3 35.4
08:00 602.4 15,663.0 26.0
09:00 487.2 4,785.9 9.8
10:00 443.0 5,518.6 12.5
11:00 461.7 7,902.9 17.1
12:00 537.2 7,785.6 14.5
13:00 604.5 13,961.9 23.1
14:00 541.9 14,275.4 26.3
15:00 608.7 12,241.2 20.1
16:00 710.2 11,603.5 16.3
17:00 695.7 7,215.4 10.4
18:00 626.8 4,747.2 7.6
19:00 406.1 1,731.9 4.3
20:00 263.1 672.1 2.6
21:00 203.1 258.4 1.3
Table 185: PassengerKm-to-ServiceKm ratio for the Bus operator
Operator name KBB Bus Operator
Table 184: Evaluation of service kilometers per time interval for the bus operator
Passenger kilometers
Service kilometers
--------------------------------------------------------- - [ ]
499 PTV AG
Chapter 7.3: Typical work flow in the PuT operator model
Illustration 164: Allocation of vehicles and operators in the line hierarchy
An operator can be allocated as the standard operator to a complete line. When creating a
new vehicle journey for this line later, the standard operator will be pre-set.
Apart from that, you can select an operator for particular vehicle journeys for example in
the timetable editor.
A vehicle combination can be allocated as the standard vehicle combination to a complete
line or an entire time profile. When creating a new vehicle journey later, the standard
vehicle combination will be pre-set.
Apart from that, you can select a vehicle combination for particular vehicle journey sections
for example in the timetable editor.
One or more units of a vehicle unit make up a vehicle combination. In this way the trains
can be more accurately modeled, because they can be made up of different coaches. The
making-up means creating or editing a vehicle combination.
7.3 Typical work flow in the PuT operator model
Typically, the following steps have to be carried out for analyses by means of the PuT operator
model. Depending on the indicators to be calculated, not all of the steps are always necessary.
1. Parameterization and calculation of PuT assignment procedures (see User Manual, Chpt.
6.2, page 951).
2. Creating PuT vehicles (see User Manual, Chpt. 2.27, page 370) and allocating vehicle
journeys (vehicle combinations, vehicle units).
3. Creating a fare model (ticket types, fare zones, fare points) (see User Manual, Chpt. 7.6,
page 1087).
4. Definition of a cost model (hourly costs, kilometer costs, vehicle costs, stop point costs, link
costs, operator costs) (see User Manual, Chpt. 7.2, page 1072).
VehComb Operator Line
Time profile
VJ section
Vehi cle journey
VehUnit
Transport system
0..1
0..1
0..1
Standard Op. StdVehComb
0..1
StdVehComb
0..1
Operator
VehComb
0..n
Read: at the vehicle combination, 0 to n
vehicle units are allocated.
1..n
VehComb VehUnit
0. .n
Standard Op.
StdVehComb
Operator that i s suggested when
creating a new vehi cle j ourney.
Vehicle combination that is suggested
when creating a new vehicle journey.
Legend
Vehicl e and Operator al locati on at t he l ine hi erarchy
500 PTV AG
5. Parameterization and calculation of the PuT Line blocking procedure (see User Manual,
Chpt. 7.1, page 1019).
6. Definition of the reference frameworks for evaluations
Definition of territories (see User Manual, Chpt. 2.21.1, page 302) and selection of the
aggregation level for evaluations by territory (see User Manual, Chpt. 7.3.2,
page 1076).
Definition of analysis time intervals for evaluations by time slice (see User Manual,
Chpt. 4.2, page 823).
Definition of operators (see User Manual, Chpt. 2.26.1, page 369) and allocation to
vehicle journeys.
Definition of the projection factor (see User Manual, Chpt. 2.41, page 550).
7. Calculation of the Territory indicators procedure (see User Manual, Chpt. 4.4.3, page 844).
8. Calculation of the PuT Operating indicators procedure for the desired indicator classes (see
User Manual, Chpt. 7.3, page 1075).
7.4 Line blocking
Subjects
Introduction into the line blocking procedure
Application example for line blocking
Data model
Line blocking description without vehicle interchange
Line blocking description with vehicle interchange
Vehicle requirement and line blocking indicators
Description of the PuT interlining matrix procedure
7.4.1 Introduction into the line blocking procedure
Application areas
One of the main tasks of strategic PuT planning is to determine the number of vehicles, which
are required to run a predefined timetable. The accumulated costs are thus to be minimized.
To solve this task use the line blocking procedure in VISUM.
Another task of strategic planning is, planning the vehicle use dependant on the capacity of the
individual vehicle combinations and the demand on vehicle journey level. To do so, the line
blocking procedure with vehicle interchange can be used.
If VISUM is applied within an overall context of a PuT operating line costing and revenue
calculation, the line blocking results can then provide a cost model module. With the vehicle
demand, line blocking provides an input parameter for determining the vehicle type dependent
costs, more precisely, the vehicle demand flows into the attribute Cost Vehicle. Furthermore,
line blocking also determines the required empty trips. The empty time thus flows into the
attribute Cost Time, the empty kilometers into the attribute Cost Distance. An overview on the
PuT cost and revenue model can be found in illustration 191.
501 PTV AG
Chapter 7.4: Line blocking
Fundamental terms
Starting point of line blocking is the timetable with the service trips, which are to be run by the
blocks (VISUM creates the blocks on the level of service trip sections). Blocks are created by
linking individual trips to trip chains, which can each be serviced by a vehicle combination. In
the simplest case, a vehicle journey is concatenated at its last stop with a subsequent service
which starts at the same stop. If such a linkage is not possible nor useful, an Empty Trip can
transfer the vehicle combination to another stop point. Only the empty trips with a real change
of location between two stop points count as interlining. If a vehicle changes from one stop
point to the depot, at the same stop point or vice versa, this is referred to as pull-in or pull-out.
This difference is important when selecting the option Interlining permissible (see User Manual,
Chpt. 7.1.3.2, page 1030). For pull-in or pull-out without change of location, neither empty trips
nor empty kilometers accumulate.
As displayed in the illustration 165, the following times are included.
Interlining times
Time required for interlining trips between two service trips which end/start at different stop
points.
Layover
Layover time at a stop until next service trip departure time.
In VISUM, those unproductive empty times without passenger transport can be calculated by
means of the line blocking calculation and will then be considered during cost calculation for
lines. The same applies to empty kilometers or empty miles.
Once line blocking has been calculated, the empty times and empty kilometers/miles of each
line block are known and can be displayed in the Line Blocks list.
Illustration 165: Example line block with pull-out trip, interlining trip and pull-in trip
6:00 6:00 7:00 7:00 8:00 8:00 9:00 9:00 10:00 10:00 11:00 11:00
I
n
t
e
r
l
i
n
i
n
g
S
t
a
n
d
S
e
r
v
i
c
e
S
e
r
v
i
c
e
P
u
l
l
-
O
u
t
Stop1
Stop2
Stop3
S
t
a
n
d
S
e
r
v
i
c
e
S
e
r
v
i
c
e
S
t
a
n
d
P
u
l
l
-
I
n
1 4 3 2
502 PTV AG
Optimization problem
For the optimization task of line blocking, there is always a conflict between the number of
empty trips (or more so the sum of empty kilometers covered on the empty trips) and the
number of vehicles to be used. By creating empty trips, the number of required vehicles can
usually be reduced, however, costs accumulate for the additional empty trips (illustration 166
bottom). On the other hand, empty trips can be saved when implementing more vehicles
(illustration 166 top). Depending on how costs are assessed by the user regarding empty trips
on the one hand and additional vehicles on the other side, line blocking can return various
optimum solutions. In addition to these two basic parameters, VISUM offers more indicators
which can be integrated into the cost function. The detailed cost function which is minimized in
this context can be found in the line blocking procedure description (see "Construction of the
graph" on page 529). The solution principle of line blocking in VISUM, which includes creating
a graph and the solution as a flow problem, is also described here.
No. Action FromSt
op
ToStop Dep Arr Line Time Length
1 Pull-Out Stop3 06:00 06:30 30 min 10 km
2 Service Stop3 Stop1 06:30 07:15 BUS1-1> 45 min 30 km
3 Interlining Stop1 Stop2 07:15 07:30 15 min 10 km
4 Layover Stop2 Stop2 07:30 08:00 30 min 0 km
10 Pull-In Stop1 10:15 10:45 30 min 10 km
Table 186: Example line block with pull-out trip, interlining trip and pull-in trip
503 PTV AG
Illustration 166: Conflict between empty trips and vehicle demand
Line blocking evaluation
Compared to previous VISUM versions, the data model for line blocking as well as the
procedure itself have been developed significantly The advantages of the new procedure are
evaluated below.
The solution as a graph flow problem now makes it possible to include long-lasting
downtimes of vehicle combinations for example in depots - in the process. Thus, the
maximum dwell time no longer exists, since a vehicle is permitted to stay in the depot or
anywhere else any period of time. The dwell time can now be evaluated by a cost rate freely
defined by the user and can thus be included in the objective function of the optimization
problem (see "Construction of the graph" on page 529).
The estimate of the number of vehicles required to run the blocks is more precise.
If closed blocks are created, the empty trips can be determined which are required to
return those vehicles shifted from one location to another, to their starting point. This
problem of returning vehicles was not taken into consideration in the previous line
blocking model.The item and effort for relocating vehicles was not considered when
determining the vehicle demand. This could result in an underestimation of the vehicle
demand and the empty kilometers or the empty time.
6:00 7:00 8:00 9:00 10: 00 11:00
SP1
SP3
SP2
SP4
1 2
3 4
6:00 7:00 8:00 9:00 10: 00 11:00
SP1
SP3
SP2
SP4
1 2
3 4
Dwell time
Vehicle 1
Vehicle journey
Vehicle 1
Dwell time
Vehi cle 2
3
4 vehicle j ourneys are completed wi th 2 vehi cles and 0 empty trips
4 vehicl e journeys are completed with 1 vehi cl e and 2 empty tri ps
Dwell time
Vehicle 1
Vehicle journey
Vehicle 1
Empty trip
Vehi cle 1
3
Vehi cle journey
Vehi cle 2
1
504 PTV AG
In the previous model, multiple blocks of a block version could be run by the same
instance of the vehicle combination, which could thus result in an overestimation of the
vehicle demand. In the new model, the block runs as long as the line blocking time
interval lasts, thus determining the number of vehicles correctly.
Blocks can be reedited manually. For that purpose, you can also create user-defined block
item types. This is how you can manually include maintenance tasks or washing cars in
block planning, for example.
Many parameters which were procedure properties in the previous model, can now be set
per block version. This enables different variants of line blocking to be compared with each
other and even afterwards the parameter settings which were used for the calculations are
still obvious.
At any time, a line block is consistent with its vehicle journey sections . Possible
inconsistency only applies to reduced pre and post preparation times or empty trips in the
case of changes to the network after line blocking.
Blocks are only subject to the demand of correctness when they are being used, they do
not necessarily have to be free of errors. This means: In many cases, you can edit the basic
network whereupon existing line blocks are not discarded. Only when evaluating them in
other procedures, line blocks have to be free of errors - for example as a basis for vehicle
requirement, empty kilometers and empty trips computation for the calculation of vehicle-
dependent costs by means of the PuT operating indicators procedure (illustration 191).
Check line block (see "Check line block" on page 525) thus helps finding and correcting
potential errors.
7.4.2 Application example for line blocking
The example below illustrates the effects caused by different parameters and rules of thumb
for planning. The simple example network (see "Demonstration example" on page 569) is used
as a basis, where additional bus lines have been inserted. You can find the example files
Example_LineBlocking_Closed.ver and Example_LineBlocking_OpenClosed.ver in the
VISUM installation.
505 PTV AG
7.4.2.1 Closed blocks according to different criteria
The first example is based on a symmetrical timetable.
Illustration 167: Line network of the example with three bus lines (red, blue and yellow)
Illustration 168: (Graphical) timetable of the example, color codes as above
506 PTV AG
Line blocking is performed three times. For each run, different criteria are set. In either case,
closed blocks are created. The results are stored in three block versions in parallel.
Line blocking by line
Only the trips of the same line are joined in a block. Vehicle demand is thus 5 vehicles.
Line comprehensive with expensive empty trips
All bus trips can be linked jointly in blocks, but empty trips are expensive compared to the
costs for using an additional vehicle. The vehicle requirement for this solution is 3 vehicles,
where the solution can manage without empty trips.
Line comprehensive with inexpensive empty trips
For this solution, the vehicle requirement is only 2 vehicles, where 2 empty trips are
however necessary.
Below, the resulting blocks are illustrated graphically and in tabular form.
Line blocking by line
For this planning variant, the option "Same line" was selected for line blocking. Because there
are two trips running at the same time, lines BUS1 and BUS2 each require 2 vehicles, another
one is required for line BUS3.
Block No. Block version code Number of blocking
days
Mean operating
time
Mean operating km
1 NoLineInterchange 1 1h 30min 55
2 NoLineInterchange 1 1h 30min 55
3 NoLineInterchange 2 21min 26
4 NoLineInterchange 1 56min 40
5 LineInterchange_Expensive 2 1h 51min 81
6 LineInterchange_Expensive 1 56min 40
7 LineInterchange_Cheap 1 2h 32min 111
8 LineInterchange_Cheap 1 2h 32min 111
Table 187: Block data of the three approaches
507 PTV AG
Illustration 169: Covering the timetable through pure line blocks
Block
No.
Index Blockin
g day
Block
item
type
Line
name
Service
trip no.
Start
time
FromSto
pPoint
Name
End time ToStopPoi
nt Name
1 1 1 Layover 0 00:00:00 X City 07:20:00 X City
1 2 1 Vehicle
journey
BUS1 2 07:20:00 X City 08:05:00 A Village
1 3 1 Layover 0 08:05:00 A
Village
08:40:00 A Village
1 4 1 Vehicle
journey
BUS1 3 08:40:00 A
Village
09:25:00 X City
2 1 1 Layover 0 00:00:00 A
Village
06:59:00 A Village
2 2 1 Vehicle
journey
BUS1 1 07:10:00 A
Village
07:55:00 X City
2 4 1 Vehicle
journey
2 5 1 Layover 0 09:35:00 A
Village
00:00:00 A Village
Table 188: Block items of the line blocks in block version 1
508 PTV AG
Line blocking without empty trips
This planning option assumes, that empty trips are more expensive compared to the costs for
using another instance of the vehicle combination. This was achieved by increasing the factor
for the cost shares (which result from empty time and empty km) in the evaluation function. In
return, the restriction to pure line blocks was dropped.
The line blocking procedure uses the possibility of switching from line to line to run a BUS2
service between each two BUS1 services. This is how both lines can be covered by two
vehicles simultaneously.
3 2 1 Vehicle
journey
3 3 1 Layover 0 08:26:00 A
Village
00:00:00 A Village
3 4 2 Layover 0 00:00:00 A
Village
08:15:00 A Village
3 5 2 Vehicle
journey
BUS2 21 08:15:00 A
Village
08:36:00 X City
4 1 1 Layover 0 00:00:00 A
Village
06:25:00 A Village
4 2 1 Vehicle
journey
BUS3 31 06:25:00 A
Village
06:53:00 B Village
4 3 1 Layover 0 06:53:00 B
Village
10:00:00 B Village
4 4 1 Vehicle
journey
BUS3 32 10:00:00 B
Village
10:28:00 A Village
4 5 1 Layover 0 10:28:00 A
Village
00:00:00 A Village
Block
No.
Index Blockin
g day
Block
item
type
Line
name
Service
trip no.
Start
time
FromSto
pPoint
Name
End time ToStopPoi
nt Name
509 PTV AG
Illustration 170: Covering the timetable through blocks without empty trips
Block
No.
Index Blockin
g day
Block
item type
Line
name
Service
trip no.
Start
time
FromStop
Point
Name
End time ToStopPo
int Name
5 1 1 Layover 0 00:00:00 A Village 06:25:00 A Village
5 2 1 Vehicle
journey
BUS1 1 07:10:00 A Village 07:55:00 X City
5 4 1 Vehicle
journey
5 6 1 Vehicle
journey
510 PTV AG
Line blocking with empty trips
This planning approach permits line changes and also empty trips since they are attractive with
regard to cost evaluation. Accordingly, the services of line BUS3, which has a diverging end
point, can each be integrated in the line blocks resulting from the second variant by interlining
(empty) trips. The vehicle demand is thus reduced to only two vehicles. This matches the
theoretical minimum, because there are (repeatedly) two service trips running at the same
time.
5 9 2 Vehicle
journey
5 11 2 Vehicle
journey
5 13 2 Vehicle
journey
6 2 1 Vehicle
journey
BUS3 31 06:25:00 A Village 06:53:00 B Village
6 3 1 Layover 0 06:53:00 B Village 10:00:00 B Village
6 4 1 Vehicle
journey
BUS3 32 10:00:00 B Village 10:28:00 A Village
Block
No.
Index Blockin
g day
Block
item type
Line
name
Service
trip no.
Start
time
FromStop
Point
Name
End time ToStopPo
int Name
511 PTV AG
Illustration 171: Covering the timetable through line comprehensive blocks with empty trips

Note: The empty trips in illustration 171run from B Village to X City following the first trip of
the day, in reverse direction before starting the last trip of the day. They are not graphically
displayed.
Block
no.
Index Blockin
g day
Block
item
type
Line
name
Servic
eTrip
Start time FromStop
Point
Name
End time ToStopPoi
nt Name
7 2 1 Vehicle
journey
7 4 1 Vehicle
journey
512 PTV AG
7.4.2.2 Open and closed blocks
Independent of the selected calendar type, open and closed blocks can be generated. Open
blocks start on the first day of the line blocking time interval (or later) and end by the latest on
the last day. For closed blocks, the last day is again followed by the first day of the line blocking
time interval, so that each end of a sequence of block items is connected with a start. This ring
closure is analog to timetable-based PuT assignment and is used to include the costs for
creating the initial situation into the model. The creation of closed blocks assures that the
created line block schedule "in perpetuo" can be traversed. The following example with an
extremely unsymmetrical timetable makes this clear.
7 6 1 Vehicle
journey
7 7 1 Empty
trip
0 09:25:00 X City 09:38:00 B Village
7 8 1 Layover 0 09:38:00 B Village 10:00:00 B Village
7 9 1 Vehicle
journey
BUS3 32 10:00:00 B Village 10:28:00 A Village
8 2 1 Vehicle
journey
BUS3 31 06:25:00 A Village 06:53:00 B Village
8 3 1 Empty
trip
0 06:53:00 B Village 07:06:00 X City
8 5 1 Vehicle
journey
8 7 1 Vehicle
journey
8 9 1 Vehicle
journey
Block
no.
Index Blockin
g day
Block
item
type
Line
name
Servic
eTrip
Start time FromStop
Point
Name
End time ToStopPoi
nt Name
513 PTV AG
Illustration 172: Unsymmetrical timetable with trips beyond 24 hours
If open blocks are created in this example, then one vehicle is sufficient, because the trip from
A Village to X City plus the empty trip in the opposing direction will require 66 minutes and the
departure of this cycle in A village is every 2 hours. The vehicle can therefore reach the starting
point before the start of the next trip.
When creating closed blocks however, two vehicles are required. The reason for this lies in the
last trip, which is scheduled for 26:05 and thus still belongs to the previous day. Only one hour
lies between the departure of this service trip and the subsequent first trip on next day, so that
the vehicle cannot return to the starting point in the meantime. When creating open blocks, this
transition to the following day is not regarded, which may result in underestimating the vehicle
demand.
Apart from the pure vehicle demand, the open block solution of course has one empty trip less.
If costs are evaluated for empty trips, this solution also simulates a less expensive situation. In
each case it has to be decided, whether the empty trip which is required to form the ring closure
has to be included in the model or not.
Note: Open blocks can be created, if the model represents the planning situation for a certain
single day or period. If the line blocking time interval however, represents a longer cycle
which is to be repeated (for example a standard day), closed blocks should be created, to
correctly determine the costs for restoring the initial state in the model.
514 PTV AG
Block No. Block version code Number of
blocking
days
Block closed Mean operating
time
Mean operating km
1 OpenBlocks 1 0 12h 51min 616
2 Self-ContainedBlocks 2 1 6h 36min 321
Table 191: Open block and closed block for the unsymmetrical example (illustration 172)
Block
No.
Index Blockin
g day
Block item
type
Line
name
Service
trip no.
Start
time
FromStop
Point
Name
End time ToStopPoi
nt Name
1 1 1 Vehicle
journey
1 2 1 Empty trip 0 03:50:00 X City 04:11:00 A Village
1 4 1 Vehicle
journey
... ... ... ... ... ... ... ... ... ...
1 31 1 Vehicle
journey
1 34 1 Vehicle
journey
2 1 1 Layover 00:11:00 A Village 02:05:00 A Village
2 2 1 Vehicle
journey
2 6 2 Vehicle
journey
2 9 2 Vehicle
journey
Table 192: Block items of both blocks in the example Block items in the recurring rhythm were omitted
for a better overview. Block 1 is open, block 2 is closed.
515 PTV AG
7.4.3 Data model
This section describes the data for the following key points:
Block version
Block
Block item and block item type
Attributes of the line blocking cost function
Downtimes in depots and at stops
Check line block
Coverage check
7.4.3.1 Block version
In VISUM multiple line blocking results can be kept simultaneously. These are stored in so-
called block versions. In this way, alternative plans with different parameter settings can be
compared easily to one another. For example, a block version where interlining is allowed and
another one where this is not allowed, can be maintained in the model. Procedures such as the
calculation of PuT operating indicators always refer to the current active block version.
Important parameters of the Line blocking procedure are attributes of a block version, so that
the parameter settings are still known afterwards, and especially the check line block can use
them for comparisons with the same parameters after changes. The block version attributes
are described in Table 193.
... ... ... ... ... ... ... ... ... ...
2 36 2 Vehicle
journey
Block
No.
Index Blockin
g day
Block item
type
Line
name
Service
trip no.
Start
time
FromStop
Point
Name
End time ToStopPoi
nt Name
Table 192: Block items of both blocks in the example Block items in the recurring rhythm were omitted
for a better overview. Block 1 is open, block 2 is closed.
Start day index First day of the line blocking time interval. The line blocking time interval
has to lie inside of the calendar period.
End day index Last day of the line blocking time interval.
Valid from Date of the start day, if a calendar is used.
Valid to Date of the end day, if a calendar is used.
Create empty trips Specifies, whether line blocking and check line block (see "Check line
block" on page 525) should create empty trips .
System routes application Specifies, whether system routes should be used for generating empty
trips.
Table 193: Block version attributes
516 PTV AG
7.4.3.2 Block
A block means, constant application of N vehicles throughout the entire line blocking time
interval. N is the number of blocking days. It is not dependent on the line blocking time interval
or the length of the calendar. The attribute Number of blocking days reflects the vehicle
demand which arises for a block. In illustration 173, a train travels from Hamburg to Vienna on
blocking day 1. On blocking day 2 the same train is not available again to travel the same
route, but has to travel in the opposite direction from Vienna to Hamburg first. It is therefore
necessary to implement a second train, thus the vehicle demand is two vehicles.
Only use active system routes Specify, if only active system routes or all system routes should be used
to create empty trips.
Regard preparation times Specifies, whether pre- and post-preparation times should be considered
for line blocking and check line block.
Short turn permitted Specifies, whether short turns should be permitted for line blocking and
check line block. This means that the layover time is allowed to differ
from the pre- and post-preparation times. The short turn properties are
set in the attributes for the maximum dwell time, the reduced pre-
preparation time and the reduced post-preparation time.
Attribute for maximum dwell
time
Specifies the stop point attribute, where the values of the maximum dwell
time is contained.
Attribute for pre short turn Specifies the vehicle journey section attribute, where the values of the
reduced pre-preparation time is contained.
Attribute for post short turn Specifies the vehicle journey section attribute, where the values of the
reduced post-preparation time is contained.
Link attribute for shortest path Specifies the link attribute, which is used as a criterion for the shortest
path search for empty trips.
Total vehicle demand Number of required instances of vehicle combinations for all blocks of
the block version
Vehicle demand (per vehicle
combination)
Number of required instances of a certain vehicle combination for all
blocks of the block version
Required vehicles for
standard vehicle combination
Number of required instances of the vehicle combination "no vehicle
combination". If no vehicle combination is specified at the vehicle journey
section, this specification is evaluated as an own vehicle combination,
whose required vehicle is accounted for by this attribute.
Vehicle unit requirement (per
vehicle unit)
Number of required instances of a certain vehicle unit for all blocks of the
block version
Table 193: Block version attributes
517 PTV AG
Illustration 173: Blocking days and vehicle demand
A block possesses the attributes described in Table 194.
Block version ID / code Reference to the block version, which the block belongs to.
Vehicle combination
number
Vehicle combination which is used to run a block. A block can be run by
only one vehicle combination, but possibly by several exemplars of this
type.
Number of blocking days Specifies, how many (similar) vehicle combinations are being used
simultaneously for this block, how high therefore the vehicle demand is for
the block. Closed blocks have arrived back at the starting position after this
number of days.
Closed Specifies, whether the block was generated for a closed time axis, if
therefore after the last day of the line blocking time interval, the first day will
follow analogously to the assignment.
Depot number Refers to a stop point, which is used as a depot for this block.
Empty trip transport system
code
Specifies which transport system should be used within check line block
when calculating the empty trip. The value is applied from the procedure
parameters for line blocking. It can also be inserted directly for manual
planning.
Not checked Specifies, whether the block was checked (0) or not (1).
Has vehicle fault Specifies, whether an incorrect vehicle was used in the block (see "Check
line block" on page 525).
Has layover time fault Specifies, whether pre- and post-preparation times were exceeded (see
"Check line block" on page 525).
Has blocking day fault Specifies, whether a blocking day without block items exists (see "Check
line block" on page 525).
Has time fault Specifies, whether a time fault exists (see "Check line block" on page 525).
Has location fault Specifies, whether a location fault exists (see "Check line block" on
page 525).
Has limit fault Specifies, whether one of the thresholds for the length or the threshold for
the duration of a user-defined block item was exceeded (see "Check line
block" on page 525).
Has forced chaining errors Specifies, whether a valid forced chaining which was not adhered to, exists
(see "Check line block" on page 525).
Table 194: Block attributes
518 PTV AG
Has vehicle interchange Specifies, whether the block was created with or without vehicle
interchange, if therefore the vehicle combination has to be compared
against the vehicle journey section attribute vehicle combination or
against the attribute vehicle combination set.
From stop point number
and name
Specifies at which stop point the block starts. For closed blocks, this
complies with the To stop point.
To stop point number and
name
Specifies at which stop point the block ends. For closed blocks, this
complies with the From stop point.
Start day index Starting day index of the block referring to the line blocking time interval of
the block version. For closed blocks, the value is always 1.
End day index Ending day index of the block referring to the line blocking time interval of
the block version. For closed blocks, the value is always equal to the
number of days in the line blocking time interval.
Start time Starting time of the block, therefore starting time of the first block item. For
closed blocks this is usually 00:00:00, unless a service trip block item
exceeds 24 hours on the last day.
End time Ending time of the block, therefore end time of the first block item. For
closed blocks this is usually 24:00:00, unless a service trip block item
exceeds 24 hours on the last day.
Block time Total block time.
Number of the line blocking time interval Number of blocking days
EmptyTime Cumulative time, which is accumulated by layovers and layover times, as
well as by empty trips and user-defined block item types of the block.
Mean empty time Empty time / (Number of blocking days Number of line blocking time interval
days)
Empty trip time Cumulative time, which is accumulated by empty trips and user-defined
block item types of the block.
Mean empty trip time Empty trip time / (Number of blocking days Number of line blocking time interval
days)
Empty Kilometers Cumulative distance, which is covered by empty trips and user-defined
block item types of the block.
Mean empty kilometers Empty kilometers / (Number of blocking days Number of line blocking time
interval days)
Operating Time Cumulative time, which is accumulated by block items of a block. Layovers
are not taken into consideration.
Mean operating time Mean operating time per blocking day and calendar day (cumulative
operating time divided by the number of blocking days and the number of
days of the line blocking time interval).
Operating Kilometers Summed up distances covered by all block items of a block.
Mean operating kilometers Operating kilometers / (Number of blocking days Number of line blocking time
interval days)
ServiceTime Sum of journey times of the service trips of a block.
519 PTV AG
7.4.3.3 Block item and block item type
Each block is made up of individual sections, which are called block items. Each block item has
a start and an end, and a start stop and an end stop. Table 195 shows the attributes of a block
item and their meanings.
Mean service time Service time / (Number of blocking days Number of line blocking time interval
days)
Service Kilometers Sum of the length of all service trip block items of a block.
Mean service kilometers Service kilometers / (Number of blocking days Number of line blocking time
interval days)
Number of lines Number of lines, which are used by the block.
Number of line routes Number of line routes, which are used by the block.
Number of time profiles Number of time profiles, which are used by the block.
Number of service trips Number of service trips, which are run by the block.
Cost distance Kilometer costs of the block, which result from the traversed service and
empty kilometers (illustration 191).
Cost vehicle Vehicle costs, which result from the number of required vehicles and the
fixed costs for a vehicle unit (illustration 191).
Cost vehicle referring to the
line blocking time interval
Cost vehicle projected to the line blocking time interval
Cost Time Hourly costs, which result from the time required for service trips and empty
trips.
Cost time with layover Hourly block costs which arise from the service trips and empty trips, as
well as from downtimes within or outside of a depot accumulated time
periods.
Leading depot number Depot with the longest dwell time. For ambiguity, the depot with the
smallest number.
Blocking day Specifies, to which blocking day the block item has been assigned.
Block item type / name Number and name of the block item type of the block item. By default, the four
block item types service trip, empty trip, layover time and layover time are
defined.
Line name Line which is run by this block item. The attribute only displays a value, if the
block item is a service trip.
Line route name Line route which is traversed by this block item. The attribute only displays a
value, if the block item is a service trip.
Direction code Direction of the line route which is traversed by this block item. The attribute
only displays a value, if the block item is a service trip.
Table 195: Block item attributes
520 PTV AG
Each block item is of a certain type (block item type). By default, there are the block item types
service trip, empty trip, stand and layover time in VISUM. You can also create user-defined
types and manually integrate them into your blocks (for example, maintenance or washing
vehicles). Table 196 shows the attributes of block item types.
Time profile name Time profile which is used by this block item. The attribute only displays a
value, if the block item is a service trip.
Service trip number Service trip which is run by this block item. The attribute only displays a value,
if the block item is a service trip.
Service trip section
number
Vehicle journey section which is traversed by this block item. The attribute
only displays a value, if the block item is a service trip.
Start day index Specifies the calendar day for the start of the block item referring to the start
day of the line blocking time interval (attribute start day index of the block
version).
End day index Specifies the calendar day for the end of the block item referring to the start
day of the line blocking time interval (attribute start day index of the block
version).
Start time Start of the block item
End time End of the block item
From stop point number /
name
Stop point where the block item starts. Complies with To stop point, if it is a
block item of type layover or layover time.
To stop point number /
name
Stop point where the block item ends. Complies with From stop point, if it is a
block item of type layover or layover time.
Duration Time period of the block item. For block items with a user-defined block item
type (for example maintenance) this duration can be edited manually.
Length Block item length. For block items with a user-defined block item type and
block items of type empty trip, you can edit the length manually.
Is in depot Indicates a downtime (item of type layover) as taking place in depot. Has no
effect for other block items.
Length until next
occurrence
Length until a block item of the same type appears in this block again. Only
available for block items of a user-defined block item type.
Time until next
occurrence
Time until a block item of the same type appears in this block again. Only
available for block items of a user-defined block item type.
Departure minute Only the minute value of the attribute start time is displayed (for example start
time: 07:20:00, departure minute: 20).
Arrival minute Only the minute value of the attribute end time is displayed (for example end
time: 07:20:00, arrival minute: 20).
Chain number Number of the chain. A chain represents a complete run through the block,
throughout the entire line blocking time interval. There are as many chains as
blocking days, and the N-th chain starts on the first day of the line blocking
time interval on blocking day N.
Table 195: Block item attributes
521 PTV AG
7.4.3.4 Attributes of the line blocking cost function
To find the optimum line block, a cost function is reduced in line blocking (see "Line blocking
description without vehicle interchange" on page 528). The attributes found in Table 197 are
regarded by this cost function.
Created by the
system
Specifies, whether the block item is user-defined.
Default duration Default value for the time period of block items of this type (default setting when
creating such a block item).
Default length Default value for the length of block items of this type (default setting when creating
such a block item).
Time limit Maximum value for the duration between two block items of this type. If a value >0
is specified here, the time elapsed between the occurrence two items of this type
may not exceed this threshold. If this is not the case, the check line block will return
a limit fault (see "Check line block" on page 525).
Length limit Maximum value for the distance being traversed by a block between two block
items of this type. If a value >0 is specified here, the distance traversed between
the occurrence two items of this type may not exceed this threshold. If this is not
the case, the check line block will return a limit fault (see "Check line block" on
page 525).
Table 196: Block item type attributes
Note: Up to and including VISUM 10 the different cost rates at vehicle units and vehicle
combinations were not used in line blocking. Because of this, existing networks do not
contain this data. For the new line blocking model this means that for each activity costs = 0
accumulate, independent of prefactors. This thus leads to an unnecessary use of vehicles
and empty trips. When changing from the old model, make sure that - at least for vehicle
costs and empty trips - positive costs rates are set.
Attribute Object Description
Vehicle requirement Activity in the block (=
service trip, layover in
depot, layover at stop
point, pre and post
preparation time,
empty trip)
Total number of vehicles required for the block version.
Cost Rate Vehicle
Unit Total
Vehicle combination Total cost which accumulates for all vehicle units of the
vehicle combination for each instance of the vehicle
combination. The cost rate referring to the AP is
projected to the duration of the line blocking time
interval.
ServiceTime Activity Service time which accumulates during the activity.
Table 197: Attributes of the line blocking cost function
522 PTV AG
7.4.3.5 Downtimes in depots and at stops
At stop points you can specify for each vehicle combination, whether the stop point should be
used as a depot by the vehicle combination. A capacity and a minimum downtime time can be
specified for each vehicle combination. The capacity is restricted to the number of vehicle
combinations, which are allowed to stop at the same time at the stop point (as a depot), as long
as the capacity > 0; for capacity = 0 the depot capacity is unlimited. Depots are therefore stop
points with downtime function. The downtime in the depot is evaluated with a cost rate that is
different (usually lower) from the cost rate for the downtime at a stop point, though both
downtimes belong to the block item type layover. A difference is made between the same stop
point in its role as a depot and as a stop point.
Cost Rate Service
Hour Total
Vehicle combination Costs which accumulate for a service hour of the
Service Kilometers Activity Service kilometers which accumulate during the
activity.
Cost Rate Service km
/ mi Total
Vehicle combination Costs which accumulate for a mileaged service
kilometer/mile of the vehicle combination.
EmptyTime Activity Empty time which accumulates during the activity.
Cost Rate Empty
Hour Total
Vehicle combination Costs which accumulate for an empty hour of the
Empty Kilometers Activity Empty kilometers which accumulate during the activity.
Cost Rate Empty km /
mi Total
Vehicle combination Costs which accumulate for a mileaged empty
kilometer of the vehicle combination.
Number of empty trips Activity 1 = activity is an empty trip, otherwise = 0.
Layovers Activity Layover at stop points which are no depots for the
vehicle combination, accumulating during the activity.
Cost Rate Hour
Layover total
Vehicle combination Costs which accumulate for a layover hour of the
vehicle combination at a stop point, which is not a depot
for the vehicle combination.
Layover in Depot Activity Layover in depots of the vehicle combination, which
accumulates during the activity.
Cost Rate Depot Hour
Total
Vehicle combination Costs which accumulate for a layover hour of the
vehicle combination in a depot.
Is Depot Specifies that the stop point is a depot. A stop point is a depot, if either
at least one vehicle combination is permissible or the entry Default
values is permissible.
Is depot for default vehicle
combination
Specifies whether the entry Default values (No combination = Not
vehicle combination specific) is permissible.
Minimum Depot Layover Minimum downtime per vehicle combination in the depot.
Table 198: Depot attributes of stop points
Attribute Object Description
Table 197: Attributes of the line blocking cost function
523 PTV AG
7.4.3.6 Empty trips
Empty trips are used for interlining a vehicle, if the end stop point of the vehicle journey section
to be carried out, does not correspond with the start stop point of the vehicle journey section
following in the block. The generation of empty trips is carried out according to the same
principles, in the check line block and in both procedures of line blocking, and has direct effect
on the data model.
The generation of empty trips via the attribute Create empty trips can basically be deactivated
at the block version. Line blockings for this block version, as well as the check line block for line
blocks in this block version, can therefore not calculate empty trips. If end and start stop point
of consecutive block items do not correspond with each other, this is characterized as a
location break.
If the generation of empty trips is generally allowed, VISUM tries calculating an empty trip to
change of location. This is always carried out regarding the empty trip transport system of the
block. For check line block this is the specified empty trip transport system (input attribute). No
Minimum layover in the depot
for the default vehicle
combination
Minimum downtime in the depot for default vehicle combination (entry
Default values).
Depot Capacity Capacity per permissible vehicle combination. This is the number of
vehicles per combination, which is allowed to simultaneously be at the
depot. For the value = 0 the capacity is not limited for the respective
Depot capacity for standard
vehicle combination
Capacity for the vehicle combination no combination (entry Default
values). For the value = 0 the capacity is not limited for the standard
Cost Rate Depot Hour Cost rate for downtimes at depots
Cost Rate Layover Hour Cost rate for downtimes at stop points, not at depots
Table 199: Cost rates for downtimes at depots and stop points at vehicle unit (cost rates in Table 197 refer
to this)
Cost Rate Layover Hour Cost rate for downtimes at stop points, not at depots
Cost Rate Layover Hour Units Sum of cost rates of the vehicle units for downtimes at stop points
Cost Rate Layover Hour Total Total cost rate for downtimes at stop points (= cost rate per layover hour
+ cost rate per layover hour from vehicle units)
Cost Rate Depot Hour Cost rate for downtimes at depots
Cost Rate Depot Hour Units Sum of cost rates of the vehicle units for downtimes at depots
Cost Rate Depot Hour Total Total cost rate for downtimes at depots (= cost rate per depot hour + cost
rate per depot hour from vehicle units)
Table 200: Cost rates for downtimes at depots and stop points at the vehicle combination (cost rates in
Table 197 refer to this)
Table 198: Depot attributes of stop points
524 PTV AG
blocks exist a priori for line blocking. Dependent on the parameter settings for each
configuration (see "Partitioning" on page 528) of a block which could occur, an empty trip
transport system is predefined and saved to the actual generated blocks. This ensures, that
with a later check the same empty trip transport system is used.
With the attribute Use system routes the block version can be defined in more detail, how the
empty trip calculation should be carried out:
Do not use system routes
Empty trips are generated through shortest path search in the network regarding the empty
trip transport system. The shortest path regarding the distance or the run time (t_PuTSys)
are calculated, for example.
Use system routes
If there is a system route for the empty trip transport system, from the origin to the
destination point, the lengths and run time are applied as values for the empty trip. If there
are vehicle combination-specific run times, these have priority. The empty trip block item
being generated has a relation to the system route used. System routes are not used
transitive. If there is no suitable system route, a shortest path search is carried out in the
network.
Use system routes exclusively
The possible empty trips are solely described through system routes, a shortest path
search is not carried out. If there is no suitable system route for an OD-pair, interlining is not
possible.
With the selection of the suitable option, the generated empty trips can be controlled in detail.
7.4.3.7 Forced chainings
For line blocking it is determined from the start, which incoming trip has to be connected to
which outgoing trip. Especially in rail services, such pre-connections are often produced due to
the short time between the connected trips. The reason being, that changing the vehicle pool
between arrival and departure is not possible. Desired through-connections between trips are
a source for such forced connections.
Forced chaining is a relation of a vehicle journey section to a follow-up vehicle journey section
on a calendar day. Forced chaining means that this transfer in the line blocking result has to be
adhered to. Line blocking therefore has to treat the thus connected vehicle journey sections
(these can be transitive whole chains) like a sole performance. Forced chainings can be
different for each calendar day. They therefore connect occurrences of vehicle journey
sections.
By definition a maximum of 24h to 1s. is allowed to lie between the arrival of the vehicle journey
section and the departure of the successor. The calendar of the successor is therefore clearly
determined by the arrival time, consequently by the calendar day of the origin vehicle journey
section. Forced chaining is valid, if the origin vehicle journey section is even operating on the
calendar day of the forced chaining, if in the described time interval, an occurrence of the
destination vehicle journey section starts after the occurrence of the origin vehicle journey
section, and if in addition the vehicle combinations of the origin vehicle journey section and the
destination vehicle journey section coincide (block does not have vehicle interchange) or the
respective vehicle combination sets have a non-empty intersection (block has vehicle
interchange).
525 PTV AG
Forced chainings are optionally considered in line blocking. In this case, as long as none of the
following conditions applies, the generated blocks meet the predefined valid forced chainings:
The same destination vehicle journey section was defined as a destination for the same
calendar day in different forced chainings. The forced chaining first found is then taken, i.e.
the one with the smaller key at the origin vehicle journey section.
The end stop point of the origin vehicle journey section does not coincide with the start stop
point of the destination vehicle journey section, and the time between is not enough for an
empty trip or empty trips are not allowed to be generated. The block then has a forced
chaining fault.
The first case can be determined through a network checking function.
If valid forced chaining applies, demands are neither made for line blocking nor for the check
line block, to comply with (potentially reduced) pre- and postpreparation times. Entering a
forced chaining has priority before a possible contradicting minimum layover time. The
required time for an empty trip has to be met. Downtimes at depots are not allowed between
forced chainings connected by service trip block items.
7.4.3.8 Check line block
In the previous VISUM version of line blocking, the blocks always had to be correct, which
means that they were not allowed to have time or location breaks. The result was, that the
blocks were deleted when making important changes in the network (for example at service
trips). This cannot be tolerated, especially when blocks were edited manually and therefore
cannot simply be restored by carrying out line blocking again. In the block data model now
available in VISUM, the consistency of line blocks with the network is assured and in return the
constant correctness of the block itself is no longer required. Instead, you have the possibility
of performing a check line block to calculate the status which codes the information on
consistency (called error flags below) for each block. These error flags provide you with
information on whether the blocks are error free and if not, in which respect there are
inconsistencies. All together there are seven error flags.
The state model in illustration 174 shows the possible states of a block and how the seven
flags are set.
526 PTV AG
Illustration 174: State model for blocks
The blocks react if the network database changes. Changes to the block version, the block
items and the vehicle journey sections are taken into consideration. Furthermore, blocks react
to changes made to the basic network parameters, especially to calendar settings.
Location break (LocationFault)
Two successive trips in a block do not match, because the successive trip does not start at
the same stop point, where the preceding trip ends.
TimeFault
Two successive trips in a block overlap with regard to time. This means, that the preceding
trip arrives later than the successive trip departs.
LayoverTimeFault
Two successive trips overlap each other in time only if for arriving trips the post-preparation
time and for departing trips the pre-preparation time is included in a block. This means, that
the planned layover time is not sufficient. In practice such an error can be ignored
sometimes, but has to be checked manually. If both trips are connected by forced chaining,
adherence to the pre- and post preparation time is not checked for this transfer, because
the forced chaining has priority.
VehicleFault
The block includes vehicle journey sections to which a vehicle combination was allocated
which does not match the block. This error can occur for example, if line blocking has
calculated a block for a standard bus and later on the user manually assigns a low-floor bus
to one of the trip sections. The attribute Has vehicle interchange is used for the evaluation
of this error. This decides whether the vehicle journey section attribute vehicle
combination or the vehicle combination set are used for comparison.
Blocking day fault (EmptyDayFault)
If there is an empty blocking day, this error is set. This means, that there is a blocking day
Adjustment to
altered data
Adjustment to
altered data
Line
Blocking
Unchecked
New Block
Block
Check
Minor Faults
Veh
Fault
No Fault Major Faults
Location
Faul t
All Mi nor Faults
Edit Block
Time Fault
Empty Day
Faul t
Li mit Faul t
Layover
Ti me Fault
Forced
Chai ni ng
Faul t
Adjustment to
altered data
Adjustment to
altered data
527 PTV AG
without a block item on any calendar day (except for layover items). In this case, an extra
vehicle has unnecessarily been planned.
LimitFault
This error can only occur, if there are user-defined block items with time or length limit
values >0. The length limit value thus specifies the length, which is allowed to be covered
at a maximum, between two actions of this type within a block. The time limit value is
analog for time periods. If one of the thresholds are exceed in the block, this is indicated by
this error flag.
ForcedChainingFault
In the block there is a vehicle journey section, which is the starting point of a valid forced
chaining, which however is not realized in the block. The vehicle journey section successor
is therefore not the destination vehicle journey section of the forced relation.
If a block contains the flag unchecked or time break or location break, it is not allowed to be
regarded by subsequent evaluations (for example in the PuT operating indicators procedure).
The other five flags however, do not restrict usability. This is necessary to be able to also
transfer plans from other systems and to be able to use it for the line performance and line
costing calculations in the procedure PuT operational indicators (see "Description of the PuT
interlining matrix procedure" on page 545), which often contain such errors (partially
deliberately).
Common check line block and forced check line block
Between the network basis and blocks, two types of inconsistencies can occur through
subsequent changes, which are not found in common check line blocks. To check consistency
in all respects, the so-called forced check can be carried out as an option (see User Manual,
Chpt. 7.1.1.5, page 1025). These are the two inconsistencies in detail:
When using reduced layover times, it could occur that no error flag is displayed, although
the block contains a layover time error (LayoverTimeFault). This is the case, if the value of
one of the three attributes describing the reduced layover time was subsequently edited or
the selection of one of these attributes changed. These user-definable attributes of stop
points and vehicle journey sections are: reduced pre-preparation time, reduced post-
preparation time and maximum dwell time. The reason for this being, that these three
attributes can be specified dynamically by the user (in particular, also indirect or user-
defined attributes can be used). Due to calculation times, it is not efficiently possible to
react to changes in these attributes and to automatically set the error flag. That is why you
have to carry out the forced version of the check line block, to make sure that all layover
time undershoots (layover time fault) are determined in the checked blocks, if subsequent
changes have been made. If no reduced layover times are used (block version property),
this problem can not occur.
Subsequent changes to the network do not cause automatic adjustments of potentially
concerned empty trips (for example when changing PuT run times of links or when blocking
links for a PuT transport system). Location and time faults can thus remain undiscovered.
Also in this case, it is - for calculation time reasons - not possible, that line blocks react to
network changes. That is why only a forced check can assure that the blocks do not contain
such errors, if the network used by empty trips has been changed subsequently.
528 PTV AG
7.4.3.9 Coverage check
For a block version it can be determined, if the version covers all trip sections in a given time
frame (from day to day, generally the analysis period) ((see User Manual, Chpt. 7.1.1.4,
page 1024)). If there is a trip section which is - for a calendar day - not bound by a service trip
in the block of the block version to be checked, the check has failed.
7.4.4 Line blocking description without vehicle interchange
The objective of the line blocking is to determine the required vehicles for a given timetable,
which minimizes the resulting costs. This section describes line blocking without vehicle
interchange. Alternatively, you can also calculate line blocking with vehicle interchange (see
"Line blocking description with vehicle interchange" on page 538).
The solution algorithm for the line blocking procedure is based on the formulation of a graph
flow problem. The procedure includes the following steps.
1. Decomposition of the problem into independent subproblems (partitioning)
2. For each subproblem, construction of a graph, where line blocking is represented as a one
good flow problem (graph construction)
3. Determination of the minimum cost flow in the graph (solution of the flow problem)
4. Decomposition of the flow in the graph into chains and aggregation to blocks
(decomposition)
7.4.4.1 Partitioning
Line blocking regards the vehicle journey sections of the model for planning, the generated
blocks thus successively traverse vehicle journey sections. For planning, either all or all active
vehicle journey sections, or - orthogonally thereto - either all sections or only those not yet
being bound in the target block version can be regarded (see User Manual, Chpt. 7.1.3.2,
page 1030). Prior to the graph construction, the problem is broken down into subproblems, so-
called partitions, which are to be solved separately. A partition consists of all vehicle journey
sections to which the same vehicle combination has been assigned. The decomposition into
these subproblems is possible, because a block is always run by exactly one vehicle
combination and there is therefore no vehicle change within the block. Also the vehicle journey
sections which do not have a vehicle combination, together form a partition. For each partition,
all further procedure steps are carried out separately. Thus, a separate graph is constructed
and solved for each partition and each result will be decomposed into blocks.
As an option, line blocking can be partitioned further according to operator, transport system
and line (see User Manual, Chpt. 7.1.3.2, page 1030). If for example the same operator is
required for the next vehicle journey, operators are partitioned additionally. In this case each
partial problem and thus each resulting block only contains vehicle journey sections of a
vehicle combination and of an operator. Operator changes can therefore not be made within a
block. Within the procedure, a separate graph is set up for each combination of vehicle
combination and operator, and the other procedural steps are carried out for each of these
graphs. illustration 175 shows an example of partitioning. These are vehicle journey sections
run by three vehicle combinations: articulated bus, standard bus, and tram. The articulated bus
vehicle journey sections are run by operator 1 and 2, whereas the tram vehicle journey
sections are run by operator 1 only. If line blocking is additionally partitioned according to
529 PTV AG
operators, five graphs will be built, for which the flow problem has to be solved separately and
the decomposition into blocks needs to be carried out separately.
Illustration 175: Example for partitioning according to vehicle combination and operator

7.4.4.2 Construction of the graph
These are the basic steps for constructing the graph:
1. For each departure and arrival of a vehicle journey section (or a sequence of vehicle
journey sections connected by forced chainings) insert a node and connect both nodes with
an edge. The following nodes are called real events. Departure and arrival in each case is
the time including poss(see User Manual, Chpt. 7.1.3.2, page 1030)ible pre- and post-
preparation times, insofar as these are taken into consideration .
Note: Capacity restrictions in depots can only be considered, if the graph is not petitioned
further than after the vehicle combination, if therefore none of the options Same operator for
next vehicle journey, Same transport system for next vehicle journey or Same line for next
vehicle journey has been selected. The reason for this being, that the capacities in depots are
each defined per vehicle combination. If a more detailed partitioning is carried out for
example according to operators, the procedure does not have the possibility of distributing
the capacity, even further to the level Vehicle combination x Operator.
Standard Bus Tram Articulated Bus
Operator1
VehComb
Operator Operator 2 Operator 1 Operator 2 Operator 1
Graph 1 Graph Graph 2 Graph 3 Graph 4 Graph 5
530 PTV AG
Illustration 176: Inserting the nodes and edges for vehicle journey sections
2. For each permissible depot for the vehicle combination as well as for each stop point, which
is the start of a vehicle journey section of the current partition (empty trips between stop
points), enter an arrival event for the time of arrival and an edge for the empty trip from the
departure event of the trip to the arrival event at the stop point or depot (so-called unreal or
"fake" arrival events are thus created). Depots are thus special stop points. In the graph,
the events at stop points and in depots are distinguished which means, that in the graph
there is one node for the stop point and another one for the depot, although the depot is
represented by the same stop point in the network.
A
B
C
depot ( = C )
"real" arrival or departure event vehicle journey secti on
time
531 PTV AG
Illustration 177: Inserting the edges for entering the depots and for empty trips between stop points
3. Analogously, insert also a departure event and an edge from there to the departure event
of the trip, however, only for each permissible depot, not for other stop points (these mean
moving out of the depots, so-called fake departure events are created in this way).
A
B
C
depot ( = C)
"real" arrival or departure event
"fake" arrival or departure event
vehicle journey secti on
empty trip between stop points
trip to depot
ti me
532 PTV AG
Illustration 178: Inserting the edges for leaving from depots

4. Insert an additional edge (the so-called Timeline or Waiting edge) between each pair of
succeeding events of a stop point or depot. Using this edge, it is possible to model waiting
(downtimes) at a stop point or in a depot. Timeline edges thus make it possible, that a block
can be continued with a new trip at the same stop point.
For line blocking you can select whether you want to create open or closed blocks. With the
generation of closed blocks, each timeline, therefore each sequence of timeline edges for
a stop point or a depot, generates a closed ring. Service trip edges and empty trip edges
can also cross the transition from the last to the first day of the blocking time interval. A
block has as many blocking days as it makes "rounds" through the calendar period, until it
has reached its starting point again.
Only for open line blocking it can be claimed, that blocks start and end in depots.
Connecting edges are then inserted before the first node and after the last node of a
timeline, from an auxiliary node to all depots. Inflow and outflow only takes place via this
auxiliary node. In this case it may occur, that no flow can be determined. This happens
when the total capacity of all depots is smaller than the number of vehicles required to
cover all actions. In such a case, line blocking is canceled with an error message.
Also in the introductory example (see "Open and closed blocks" on page 512) you can find
a note concerning open and closed line blocks.
Note: If interlining is prohibited (see User Manual, Chpt. 7.1.3.2, page 1030), only edges from
and to that depot are inserted, which is represented by the same stop point in the network.
Thus, interlining is not possible in this case, the vehicle combination can however, enter a
depot and subsequently return to the same stop point for the start of the next trip.
A
B
C
depot ( = C)
1
2
3
4
5
6
7
vehicle journey
empty trip between stoo points
trip from depot
trip to depot
ti me
533 PTV AG
5. The graph is now simplified, by combining nodes with the same accessibility and by
deleting equivalent empty trip edges (which provide access to the same departure). The
graph after the edge reduction can be seen in illustration 179.
Illustration 179: Example graph after inserting the timeline edges and edge reduction
6. For the formulation as a flow problem, it is necessary to define a lower capacity limit and an
upper capacity limit to the edges (which is the number of vehicles which can maximally or
minimally flow via an edge). The following applies:
The lower limit of the capacity on the vehicle journey sections is 1 (because it is
mandatory that each vehicle journey section is really traversed).
All other edges have a lower capacity limit of 0 (because traversing is not mandatory,
for example for empty trips).
The upper limit for the vehicle journey section edges is also 1 (because each vehicle
journey section should only be traversed exactly no more than once).
Empty trip edges as an upper limit have the number of empty trips, which they represent
(this is only greater than 1, if in the framework of edge reduction, edges were
combined).
Edges along the Timelines, if we are talking about a depot, use the depot capacity as
upper limit. For all other Timelines the upper limit is not restricted.
7. To be able to determine a cost-efficient flow, the edges with costs have to be evaluated in
the last step. These are described by a cost function analog to the perceived journey time
for PuT assignments (see "Perceived journey time" on page 456). This cost function is
made up of summands, which each multiply one property of the edge (therefore the activity
described by the edges) by a factor and a cost rate. The cost function is as follows:
Costs = Required vehicles Coefficient Cost rate vehicle unit total
A
B
C
depot ( = C)
1
2
3
4
5
6
7
vehicle journey
trip from depot
trip to depot
ti me
timeline edge
534 PTV AG

Which cost components have an effect on an edge, depends on the edge type. The cost
components for the individual edge types are the following.
Service trip edges
Service time describes the duration of the vehicle journey section (The costs for the trip
itself are irrelevant for solving the problem, because each edge is allocated with exactly
one flow of 1 and there is thus no alternative allocation. To display the result, service
trip edges are still evaluated with the service trip cost rates of the vehicle combination
for duration and distance.)
ServiceKm/Mi describes the distance covered by the service trip
Layover describes the duration between the FromNode's point in time and the
departure from the FromNode plus the duration between the arrival at the ToNode and
ToNode's point in time.
Empty trip edges
Empty time describes the duration of the empty trip
EmptyKm/Mi describes the distance covered by the empty trip
Layover describes the duration between the FromNode's point in time and the
the ToNode's point in time, in case it is a normal stop point
Depot layover describes the duration between the FromNode's point in time and the
the ToNode's point in time, in case it is a depot
Timeline edges
Layover and layover depot describe the length of the time period between the points in
time of the nodes which are connected via the edge
To evaluate the vehicle demand, for each edge which traverses a selected point in time, the
cost rate for the vehicle combination is added to the evaluation. Because each vehicle
combination has to traverse this evaluation point in time exactly once, the vehicle demand
is thus counted and evaluated.
As an interim result, an evaluated graph is available, for which a flow with minimum costs is
determined in the following step.
7.4.4.3 Flow problem solution
With the graph constructed above including the evaluation, the cost minimum flow is now
determined. The target cost function can thus be parameterized as described in the previous
+ Service time Coefficient Cost rate hour service
+ ServiceKm/Mi Coefficient Cost rate Km/Mi service
+ Space Coefficient Cost rate hour empty
+ LeerKm/Mi Coefficient Cost rate Km/Mi empty
+ Number of empty trips Coefficient
+ Layover Coefficient Cost rate hour layover
+ Service time depot Coefficient Cost rate hour depot
Note: The coefficients also have an effect on the cost rate for "no vehicle combination".
535 PTV AG
procedure step. The user can thus especially control modeling of the basic conflict between
minimizing empty trips and minimizing vehicle demand, which is described in the introduction.
illustration 180 schematically shows such a cost minimum flow, where multiple flow units
(vehicle combinations) are indicated on an edge with lines piled on top of each other. To make
it easier, neither costs nor capacities are noted here. The illustration however shows, that all
vehicle journey sections are traversed by exactly one vehicle combination. The graph also
shows, which empty trips even have to be traversed at a minimum cost flow (i.e. all edges
crossed by the flow). Altogether there are two empty trips one from C to A and one from B
to C. The evaluation line cuts three edges, that is why the vehicle demand is 3.
Illustration 180: Optimal cost flow in the example graph
As a result of this step, a cost-efficient flow exists, the vehicle demand is known and which are
the necessary empty trips. Not known yet however, are the blocks themselves, therefore at
which stop points blocks start and end, and the routes of the blocks in the optimal flow.
7.4.4.4 Decomposition of the flow into blocks
The cost-efficient flow in the graph from the previous step can be displayed as blocks in
different ways. Regarding the costs, each of these solutions is of equal quality and thus
optimal. The decomposition step has to break up the flow into chains in the graph, by allocating
an outgoing flow unit at each node. Each generated chain thus corresponds to one block.
illustration 181 and illustration 182 show two possible examples, how the cost-efficient flow
can be decomposed into blocks.
A
B
C
depot ( = C)
1
2
3
4
5
6
7
vehicle j ourney section
trip from depot
trip to depot
ti me
timeline edge optimum flow evaluation line
536 PTV AG
Illustration 181: Example 1 for the decomposition into blocks
A
B
C
depot ( = C)
1
2
3
4
5
6
7
vehicle journey
trip from depot
trip to depot
time
timeline edge block 1 bl ock 2 bl ock 3
537 PTV AG
Illustration 182: Example 2 for the decomposition into blocks
This independent optimization problem can be resolved according to different criteria. In
VISUM there are two criteria, which can also be combined with each other:
The structure of the transitions between vehicle journey sections in the block can be
influenced by the following options
Differentiated duration of standstills: The distribution of the standstill times is as
irregular as possible, in other words, there are more short and long standstills than
average standstill times. The aim of this is to obtain long standstills which can be used
as maintenance time slots.
Even duration of standstills: The distribution of the standstill times is as even as
possible. Such blocks are exceptionally resistant to disturbances.
Line purity: It is attempted to only run trips of the same line in a block or at least avoid
line changes within a block as often as possible.
No specific requirements: In this dimension, no requirements are set concerning the
result.
If closed blocks are generated, the duration of the blocks can also be influenced with the
options
Preferably, build long blocks: Blocks have as many blocking days as possible. This
means that the single vehicles traverse multiple line paths. In the most extreme case,
all service trips of a partition are covered by a single line block.
Preferably, build short blocks: Blocks have as few blocking days as possible.
No specific requirements: In this dimension, no requirements are set concerning the
result.
A
B
C
depot ( = C)
1
2
3
4
5
6
7
vehicle journey
trip from depot
trip to depot
time
timeline edge block 1 bl ock 2 bl ock 3
538 PTV AG
7.4.5 Line blocking description with vehicle interchange
Line blocking with vehicle interchange differs from that without vehicle interchange, in that the
vehicle combination to be used is not strictly defined for each vehicle journey section. In fact,
the procedure has the possibility of selecting the best vehicle combination specified in the
attribute vehicle combination set. Different criteria are possible, which can be weighted
against each other in a subordinate objective function:
Selection according to costs: Different costs are involved with the selection of a vehicle
combination, which flow into the objective function.
Selection according to capacity: For the selection, a comparison between the trip volume
(Assignment results or count data) can be carried out on the one hand and the (seat)
capacity of the vehicle combination on the other hand. Not the covered demand provided
by the capacity, is included in the objective function.
Selection according to availability: The number of available vehicles can be predefined by
unit level. The selection is made, so that this restriction is adhered to. The number of
vehicles used in addition to the ones available are included into the objective function.
Line blocking with vehicle interchange thus goes beyond the application area of line blocking
without vehicle interchange (see "Line blocking description without vehicle interchange" on
page 528) and also covers the following application areas.
Planning the vehicle use depending on the demand, at the same time considering block-
related restrictions.
Reduction of the calculated vehicle requirement by making the vehicle use more flexible,
with the (possibility of) replacing a vehicle combination with another, for example because
of technical restrictions.
The procedure is based on the line blocking without vehicle interchange and integrates this as
a procedural step into its entire process. Compared to this one it is not about an analytical
procedure, but an iterative search procedure which in general finds very good solutions, but
never an optimal one regarding the objective function.
As another distinctive feature, several complete and equal solutions of the given line blocking
task (parameter number of solutions per iteration), exist for each time of the procedure.
These are changed iteratively and evaluated. If there is no improvement of the objective
function value (convergence) or if the defined maximum number of iterations has been
reached, the procedure is stopped and the best solution is provided.
The procedure is divided into the following steps.
1. Initial selection of the vehicle combination from the specified vehicle combination set for
each vehicle journey section and each solution.
2. Line blocking without vehicle interchange for this selection for each solution
3. Evaluation of the solution and convergence check.
4. Determining and merging selections, which have lead to good solution properties, and new
start from step 2.), until convergence applies or the maximum number of iterations has
been achieved.
Because the line blocking is carried out as in the procedure without vehicle interchange (see
"Line blocking description without vehicle interchange" on page 528), for defined selection of
the vehicle combinations, the following additional components are necessary to understand
the procedure:
539 PTV AG
Selection principles of vehicle combinations
Solution evaluation via objective function
Parameters and convergence
7.4.5.1 Selection principles of vehicle combinations
The selection of vehicle combinations from the set specified for each vehicle journey section,
of the vehicle combinations which can be used, is the central component of the procedure. The
challenge as a search procedure is to produce as many different selections and to avoid such
selections which lead to poor solutions. This task can be compared with the connection search
per Branch&Bound within the timetable-based assignment.
In the initial step of the procedure there are no solutions yet. Heuristic procedures play a bigger
role for the selection. In all other iterations the selection is always made on the basis of a
solution from the preceding iteration, so that this solution can be further developed. But here
parts of the solution are also discarded and rebuilt. The selection is carried out initially, to
create the start solutions for the first iteration according to the following criteria:
For an individual occurrence of a vehicle journey section the selection is carried out
randomly
according to the volume of the service trip and capacity of the vehicle combination - i.e.
a selection which probably leads to good coverage of the demand,
according to the specified number of vehicles, considering the vehicles already used,
by edges without selection or already selected edges - therefore a selection which
probably leads to an equal volume,
according to the neighboring service trips without selection - i.e. a selection which
probably lead to productive blocks.
Based on individual occurrences of vehicle journey sections, for which a selection has
already been made, analog choices are made as far as possible
for all service trips of a line,
for all other occurrences of the same vehicle journey section,
for individual neighbors or entire chains neighboring below each other,
for the compliance of the flow conditions particular favorable occurrence of vehicle
journey sections.
The selection can be applied from the attribute Vehicle combination number of the
vehicle journey section, alternatively for all vehicle journey sections from the specifications
for the line blocking without vehicle interchange, if the vehicle combination in the set is
included in the permitted vehicle combinations set. Without vehicle interchange, the line
blocking solution thus becomes a starting solution.
If a reference solution is specified and the proximity is required, the selection can be
applied from this reference solution.
In all later iterations, each solution is generated from an existing solution. The relative
inefficient parts of the solution are determined, who's selection is discarded and based on the
new ones retained, analog choices made according to the same criteria as in the initial stage.
In addition the following principles are available for the solution change:
540 PTV AG
Replace empty trips of a vehicle combination, so that for this vehicle combination a suitable
temporal and local service trip is selected, for which another vehicle combination has so far
been selected.
Change the choice simultaneously for entire blocks, so that the configuration regarding the
costs is convenient.
Change the choice simultaneously for entire blocks, so that the configuration regarding the
OD demand coverage is convenient.
Change the choice simultaneously for entire blocks, so that the configuration regarding
retaining the available number of vehicles is convenient.
7.4.5.2 Solution evaluation via objective function
Line blocking with vehicle interchange uses an objective function for evaluating the quality of a
solution. The objective function measures solution properties, where there is room for
improvement. It comprises the objective function of line blocking without vehicle interchange
(see "Construction of the graph" on page 529) as a component.
The following solution properties are evaluated:
Costs: Objective function of line blocking without vehicle interchange. This especially
comprises the number of vehicles per vehicle combination as well as the service km and
empty km and service times and empty times, as well as the layovers within and outside of
a depot
Number of vehicle units: Exceeding the predefined number of available vehicle units
Consideration of volumes: Too low capacities (total or seats) regarding the OD demand
Line purity, local definition: Number of transfers between the different lines
Line purity, global definition: Number of different lines in a block
Number of vehicle combinations per line: Number of different vehicle combinations used on
the same line
Regularity: Number of vehicle journey sections, who's vehicle journey section occurrence
lies in at least two different blocks or blocking days
Difference from reference solution (only when a reference solution has been specified):
Difference to this reference solution in form of deviating transfers between vehicle journey
sections
The following function is used as an objective function (OF), which is based on the comparison
between the calculated and the estimated values for each of the objective function
components:
where
c
i
Influential factor (Procedure parameters) for the indicator i, where c
i
> 0
of
i
Objective function component for indicator i according to the upper list
comparison
i
Comparison value for indicator i on a comparable scale
OF
c
i
of
i
c
j
comparison
i
--------------------------------------------------

i
=
541 PTV AG
The individual component properties are apply as follows:
Component Calculation
Costs The objective function component costs evaluate the solution according to the
same criteria as the line blocking without vehicle interchange.
It therefore applies
of
Costs
= f
e
Costs(e) (f
e
= Flow on edge e)
For the comparison value, vehicle combinations are randomly selected and thus a
solution calculated. The costs are then used as a comparison value.
Number of vehicle
units
The sum is calculated over all vehicle units, across the number of used but not
available vehicles per vehicle unit
The comparison value comparison
vehicle
is 1 (Note: This is how you achieve very
strong penalization, because this criteria must apply "strongly", if it is even used)
Consideration of
volumes
The volume of a trip section is defined according to the parameter setting as
Vol
VJS
= (Volume(ST item) / Number of vehicle journey sections via this ST item)
or
Vol
VJS
= max (Volume(ST item) / Number of vehicle journey sections via this ST
item)
Then Cap
VJS
= selected capacity (seat or total) of the vehicle combination:
of
Volume
= VJS with Vol
VJS
> Cap
VJS
( Vol
VJS
- Cap
VJS
)
The value of this objective function component, which applies for the random
solution, used for cost estimation, is used as a comparison value.
Line purity, local
definition
The number of line changes between successive service trips in the block are
measured. The benchmark is the number of occurrences of vehicle journey
sections in total (therefore the number of all transitions between successive service
trip items).
Line purity, global
definition
The number is calculated minus 1 of the line per block, summed up over all blocks.
The comparison value is the number minus 1 of the lines per partition, summed up
over all partitions.
Regularity Dispersion of the occurrences of vehicle journey sections is measured for different
blocks or optionally for different blocking days.
of
regularity
= Sum of vehicle journey sections |{Blocks / blocking days which contain
the VJS}| - 1
comparison
regularity
= (Sum of occurrences of the VJS in the line blocking time
interval 1)
Distance to
starting solution
The number of transitions from vehicle journey section to vehicle journey section,
which differ from the comparison solution, are measured.
The comparison value is the number of all transfers from vehicle journey section to
vehicle journey section in the comparison solution.
Table 201: Objective function components for line blocking with vehicle interchange
Note: Objective function components, which are not relevant for the specific planning task,
can be switched off by setting the respective coefficient to 0. This is recommended, because
optimization up until the solutions, considering the hidden properties, is thus suppressed.
Finding good solutions regarding the remaining criteria is accelerated accordingly.
542 PTV AG
7.4.5.3 Parameters and convergence
The line blocking procedure with vehicle interchange can be controlled via several parameters.
The procedure is iterative, by first generating a number of solutions, which are then improved
step by step. If there is no improvement within a specified number of iterations, convergence
has been reached and the procedure is ended.
As a heuristic procedure, coincidence plays a decisive role, especially as there are many
equivalent solutions. By using a random number generator, the procedure is deterministic in
the sense, that each calculation with the same data and parameters achieve the same result.
You can however modify the procedure by changing the parameter Random seed and thus for
otherwise identical data calculate alternative solutions.
These are the following parameters for controlling the procedure run:
7.4.6 Displaying and editing blocks in the timetable editor
In VISUM blocks are illustrated as Gantt charts (block view). Compared to the time-distance
diagram, which only displays blocks in as far as the bound trips can be illustrated on the stop
sequence, a natural view on a block as a whole is possible. All block actions are displayed as
well as all other information such as header data, etc., but also all empty trips and layovers.
The display can be restricted according to different filter criteria, to increase the clarity, and can
be configured extensively with graphic parameters in the usual way.
Alongside the pure display, block display also allows blocks to be edited. Besides the block
actions, vehicle journey sections are also displayed, which can be inserted or removed from a
block via drag&drop. It is thus possible, to reedit the blocks, generated with one of the two line
blocking procedures, or completely manually generate blocks. All other block-related functions
such as check line block, coverage check and definition of forced chainings can be initiated
from the line block view.
Parameters Meaning and notes
Use reference
solution
A reference solution is a block version containing blocks. If this option is
selected, a solution is searched which can be compared with this reference
solution. A different block version should be selected as reference solution, than
the current one used.
Maximum number of
iterations
Number of iterations, after the procedure is ended, if convergence occurs. This
value should be a multiple of the number of iterations without improvement.
Number of iterations
without improvement
If for N iterations no improvement of the target function value is determined, the
procedure regarded as converged and is ended. Reasonable values depend on
the task size, should not however, exceed 10 to 20.
Number of solutions
per iteration
Number of simultaneous existing solutions per iteration. The more freedom the
planning task offers, the greater this value should be. The minimum permissible
value is 10, generally however 20 to 100.
Random seed By changing this value, the random item of the procedure can be influenced to
achieve, with otherwise same data and parameters, a different procedure und
thus a different result.
543 PTV AG
Illustration 183: Example for block display of a block with 5 blocking days
Line block view is part of the timetable editor. The display details as well as editing are
described there (see User Manual, Chpt. 7.1.5, page 1043).
7.4.7 Vehicle requirement and line blocking indicators
The vehicle requirement and line blocking indicators, are also used to asses the economic
efficiency of an existing PuT supply and to derive improvement potentials for the operator.
7.4.7.1 Vehicle requirement
The vehicle demand can be displayed both as length proportional and time proportional. It
is output for the objects of the line hierarchy as well as for territories precisely broken down to
boundaries. Fr the following network objects, both sets of indicators can be calculated for the
analysis period, the analysis horizon and by analysis time interval.
Vehicle journeys
Time profiles
Line routes
Lines
Main lines
Operators
Transport systems
Territories
Territory PuT detail
Indicator Description
Number of Vehicles
(in proportion to
length)
Length of the vehicle journey section divided by the total length of all service trip
block items in the block, multiplied by the number of blocking days of the block.
Table 202: Line blocking and vehicle requirement indicators
544 PTV AG
The allocation of the indicator value for the precise calculation by territory is performed as
follows.
The time proportion of a vehicle journey section in the total time of all vehicle journey
sections of the block (called NumBlocksVJS below) is determined.
For each link that - after a temporal intersection of the vehicle journey section with analysis
period or time interval - is identified as traversed, the proportional number of vehicles is
determined according to the time proportion of the link at the VJS NumBlocksVJS. This
value is then summed up in the line hierarchy and hence called NumBlocksVJSOnLink.
For the precise calculation by territory, VISUM multiplies the length proportion of the link
in a territory NumBlocksVJSOnLink per link. Here, VISUM always uses the length-
oriented proportion since the precise link calculation by territory is always based on this
criterion. The "error" resulting from this is minimal however, because it only affects links
that lead across a territory border. The proportion of all other links is 1.0.

7.4.7.2 Distribution of empty trips and empty times to service trips
As line costing is based on service trips, empty times and empty kilometers of a line block have
to be allocated to the service trips served by the block. Based on this, costs can be calculated
by the PuT operating indicators procedure.
The example below illustrates the impact of the four variants provided for distribution of empty
times and empty distances to service trips. The operating time is calculated from empty time
and service time. Similarly, the operating distance results from empty distance and service
distance. Operating time and operating distance are required for cost calculation.
Hourly costs = Operating time Vehicle-Hour cost rate
Kilometer costs = Operating distance Vehicle-Kilometer cost rate
Number of vehicles
(in proportion to
time)
Duration of the vehicle journey section divided by the total duration of all service
trip block items in the block, multiplied by the number of blocking days of the block.
Note: To get a result for the indicators number of vehicles (length proportional) and number
of vehicles (time proportional), you have to first calculate the line blocking procedure and then
the procedure PuT operating indicators.
Variant 1: EmptyTime from Pre+PostPrepTime (2+3 min) of veh. journey / no EmptyKm
ServiceTrip ServTime EmptyTim
e
OpTime ServKm EmptyKm OpKm
1. 6:30 7:15 0:45:00 0:05:00 0:50:00 30 km 0 km 30 km
2. 8:00 8:15 0:15:00 0:05:00 0:20:00 10 km 0 km 10 km
3. 8:30 9:15 0:45:00 0:05:00 0:50:00 30 km 0 km 30 km
4. 9:30 10:15 0:45:00 0:05:00 0:50:00 30 km 0 km 30 km
Total 2:30:00 0:20:00 2:50:00 100 km 0 km 100 km
Table 202: Line blocking and vehicle requirement indicators
545 PTV AG
7.4.8 Description of the PuT interlining matrix procedure
The procedure PuT interlining matrix calculates transport system-specific skim matrices for
interlining trips between the stop points of a transport system. For each generated relation
between two stop points, the specific value calculated for the shortest path between the stop
points is returned for the selected indicator. Relations are created for the selected type of pairs:
between two stop points, between two active stop points or only between the stop points, which
are start or end stop point of a service trip of the transport system. Optionally, system routes
can be considered. In this case, the indicator values for a relation are determined from the best
system route, which leads directly from the start stop point to the destination stop point and
which is permissible for the transport system. Transitive search via the system routes is not
carried out. For each relation it is thus possible, to individually overwrite the O-D value,
determined from the network.
Variant 2: From EmptyTime/EmptyKm of line block weighted by service trips
e
1. 6:30 7:15 0:45:00 0:33:45 1:18:45 30 km 7.5 km 37.5 km
2. 8:00 8:15 0:15:00 0:33:45 0:48:45 10 km 7.5 km 37.5 km
3. 8:30 9:15 0:45:00 0:33:45 1:18:45 30 km 7.5 km 37.5 km
4. 9:30 10:15 0:45:00 0:33:45 1:18:45 30 km 7.5 km 37.5 km
Total 2:30:00 2:15:00 4:45:00 100 km 30 km 130 km
Variant 3: From EmptyTime/EmptyKm of line block weighted by service time
e
1. 6:30 7:15 0:45:00 0:40:30 1:25:30 30 km 9 km 39 km
2. 8:00 8:15 0:15:00 0:13:30 0:28:30 10 km 3 km 13 km
3. 8:30 9:15 0:45:00 0:40:30 1:25:30 30 km 9 km 39 km
4. 9:30 10:15 0:45:00 0:40:30 1:25:30 30 km 9 km 39 km
Total 2:30:00 2:15:00 4:45:00 100 km 30 km 130 km
Variant 4: From EmptyTime/EmptyKm 50% before and 50% after service trip
e
1. 6:30 7:15 0:45:00 0:52:30 1:37:30 30 km 15 km 45 km
2. 8:00 8:15 0:15:00 0:30:00 0:45:00 10 km 5 km 15 km
3. 8:30 9:15 0:45:00 0:15:00 1:00:00 30 km 0 km 30 km
4. 9:30 10:15 0:45:00 0:37:30 1:22:30 30 km 10 km 40 km
Total 2:30:00 2:15:00 4:45:00 100 km 30 km 130 km
Table 203: Example illustrating different variants of distribution of empty time and empty kilometers on
individual service trips.
546 PTV AG
In the line blocking procedure (see User Manual, Chpt. 7.1.3, page 1029), the interlining matrix
is used to determine the duration and length for each empty trip between stop points. The PuT
interlining matrix procedure is also provided as a separate procedure, so that the output
matrices can be imported in external timetable or crew scheduling systems, as interlining
matrices for line blocking.
Table 204 shows an example of a PuT interlining matrix, where the values of the shortest path
(determined on the basis of the attribute t-PuTSys) between all relations between two stop
points are listed. If in a cell the value is 999999, this means, that there is no path between the
two stop points.

7.5 PuT fare model
Subjects
Short overview
Ticket types
Fare systems
Fare calculation
Application of fares
7.5.1 Short overview
illustration 184 offers an overview of the network objects which belong to the fare modeling in
VISUM.
SP20 SP21 SP22 SP24 SP50 SP56 SP71 SP74 SP86
SP20 0 16 36 61 34 73 121 108 999999
SP21 16 0 20 45 50 89 137 124 999999
SP22 36 20 0 25 70 109 157 144 999999
SP24 61 45 25 0 95 134 182 169 999999
SP50 34 50 70 95 0 39 87 74 999999
SP56 73 89 109 134 39 0 48 35 999999
SP71 999999 999999 999999 999999 999999 999999 0 999999 999999
SP74 108 124 144 169 74 35 13 0 999999
SP86 121 137 157 182 87 48 999999 13 0
Table 204: PuT interlining matrix with t-PuTSys between stop points
547 PTV AG
Chapter 7.5: PuT fare model
Illustration 184: Possibilities of fare modeling in VISUM
The VISUM fare model is based on fare systems and ticket types.
A fare system is a set of lines, for which a joint fare system exists. Each PuT operator often
has his own fare system, in transport associations a fare system can also include lines of
different operators.
A ticket type describes how the fare is calculated for a PuT connection or part of a connection.
Each ticket type obeys one of four calculation methods ("Fare structure"):
Distance fare: The fare is conform with the distance covered, which is measured by fare
points.
Zone-based fare: The fare is conform with the number of traversed fare zones.
From-to zone-based fare: The fare is only dependent on initial fare zone and target fare
zone, this is therefore a matrix fare.
Short-distance fare: A special fare for paths, which do not exceed the specified threshold
regarding distance, run time and/or the number of stops.
The four fare structures are described in detail as follows (see "Base fare calculation" on
page 550).
For each demand segment you can determine which ticket types are used in a fare system.
In particular for each demand segment, several ticket types may exist for each fare system.
With the allocation of lines (and PuT-Aux transport systems) to fare systems, each path leg of
a PuT connection belongs to one or more fare systems.
Fare systems are generally independent. The total fare for a connection is normally the sum of
the fares to be paid for the individual fare systems. With specific transfer fares you can
548 PTV AG
however model, that a change between fare systems costs extra or a reduction is given (see
"Initial fare and transfer fare" on page 556).
Determining the ticket to be used for each fare system
Within the fare systems, the possibilities of fare modeling are very versatile.
A basic property of a fare system is the "Fare-reference". This expresses, whether a ticket has
to be bought for each individual path leg or if it can be used for successive or even all path legs
of a connection. All three cases are more often found in practice.
As mentioned, several ticket types (per demand segment) may be available within a fare
system. Let's take for example, a fare system is composed of fare zones and the normal fare
depends on the number of traversing fare zones. For trips of maximum ten minutes, an
inexpensive short-distance ticket applies independent of the fare zones. For trips from and to
the airport, a special airport ticket has to be bought.
Generally speaking the crucial question is when creating a fare system, which ticket types are
allowed to be used for which connections and how much freedom does the passenger have
when selecting a ticket.
The applicability of the different ticket types plays an important role. If the defined conditions
in the ticket type have been breached, the ticket cannot be used and another ticket has to be
used. In the example, the short-distance ticket is invalid if the maximum run time of 10 minutes
has been exceeded and the airport ticket only applies for paths from and to the airport.
Distance-based or zone-based ticket types can be modeled so that they are only valid on
certain connections. You can thus define where the applicability limits of the ticket lie.
Ticket types have ranks, which can be used to express a hierarchical order within a fare
system. In combination with the previously described applicability of tickets, a logic thus
applies for determining tickets to be used, for a given connection or its path leg(s): Amongst all
applicable ticket types it is the one with the highest rank.
In the example shown, the special airport ticket must have the highest rank, because it has to
be used for all connections, whose start or target is the airport . For all other connections the
airport ticket cannot be used after construction, which is why the ticket type with the second
highest rank is regarded, in this case the short-distance ticket. This applies if the connection
fulfills the requirements of the short-distance ticket. If not, the normal zone-based fare with the
lowest rank is applied.
Do you want to illustrate that the passenger has the free choice between several ticket types,
then allocate the same rank. The most inexpensive ticket with the highest rank is selected
amongst all applicable tickets.
Ranking order of fare systems
It may occur, that lines do not just belong to one fare system, but are part of several fare
systems. A regional train can for example, be used both within the urban network area with a
network ticket and beyond the boundaries of the transport association with a long-distance
ticket. Urban network and long-distance transport are separate fare systems with completely
different fare structures, the regional train line however, belongs to both.
If a line belongs to several fare systems, a fare within each of these fare systems can generally
be determined according to the procedure described above. However, in reality the passenger
cannot freely select between the two different fare systems, in each case. A typical fare
condition would be for example, that the regional train on trips within the transport association
549 PTV AG
area can only be used with ticket types of the urban network fare system and long-distance
transport tickets only have validity, if used beyond the transport association boundary (see
"Procedure for ambiguous fare systems" on page 563).
To express such ranking, you can define fare system ranks. These ranks are only relevant if in
your network model, lines belong to several fare systems, because otherwise the fare systems
are evident for all path legs of a PuT connection.
In general the line of each path leg of a PuT connection belongs to several fare systems. A set
of allocated fare systems therefore exists for each path leg. The entire connection can
principally be "covered" by any combination of items of these fare system sets. The fare
system ranks then define a logical order within the combinations: all combinations with the
smallest maximal fare system rank are considered first, and thus the one selected which can
be applied and provides the lowest fare. If none is applicable, all other combinations with the
next highest rank follow. If there are no valid fare system combinations, the global fall-back fare
of the fare model is charged.
Because you can allocate ranks both on the ticket type level and the fare system level to model
specific fare conditions, all together great flexibility is achieved for fare modeling.
7.5.2 Ticket types
A ticket is valid for a path leg of a PuT connection, for several path legs of a connection or even
the entire connection. Validity depends on the properties of the fare system (see ""Fare-
reference" of a fare system" on page 560). This section first talks about applicability,
calculation logic and other ticket type properties. To make it easier, this chapter does not
always explicitly point out that a ticket type, if necessary, only applies to individual path legs of
a connection, but talks about connections or paths.
A ticket type describes how the fare should be calculated. The fare components of a ticket type
include the base fare, the initial fare, the transfer fare as well as the TSys-specific
supplements:
Fare component Description
Base fare The base fare is calculated from the fare structure of the ticket type. Four fare
structures can be selected:
Distance-based fare
Zone-based fare
From-to zone-based fare
Short-distance fare
Initial fare The initial fare is charged additionally for the first path leg of the path, namely
dependent on the fare system of the first path leg.
Transfer fare The transfer fare is charged additionally for each transfer on the trip, where a
new ticket has to be bought, namely dependent on the fare systems where the
transfer is made.
A transfer procedure may have both positive as well as negative effects on the
fare, i.e. the transfer fare is either
a surcharge or
a reduction.
550 PTV AG
Essential characteristic of a ticket type is the fare structure, which defines the calculation
method for the base fare:
The distance-based fare is based on distance-based fare items: The base fare is calculated
based on the number of traversed fare points.
The zone-based fare is based on the zone-based fare items: The base fare is calculated
based on the number of fare zones traversed.
The From-to zone-based fare is based on From-To zone-based fare items: The base fare
is the entry of the pair, initial fare zone and target fare zone from the connection of a fare
matrix, which is indicated by (From-fare zone, To-fare zone).
The short-distance fare is based on short-distance fare items: The base fare applies for
tickets whose length, duration and number of stops does not exceed the defined
thresholds.
The following section describes the four fare structures in detail.
For fare modeling it is important to know which ticket types can be applied for which
connections. In the case of the fare structure "Short-distance fare" the restricted applicability is
clear, however, the other three fare structures may also have restrictions: Zone-based fares
generally cannot be applied on connections, which lie outside of the considered fare zones.
Both From-to zone-based fares, as well as distance-based fares may only refer to certain pairs
of fare zones or certain distance classes.
The rank defines the ticket type hierarchy within a fare system and is relevant when a fare
system comprises several ticket types. The definition of the rank is described in several
examples (see "Ticket selection in a fare system" on page 562).
Via the utility rate the conversion factor is specified for a single trip. It is included in the
calculation of the fare of a PuT path.
7.5.2.1 Base fare calculation
The calculation of the base fare is based on the fare structure of the ticket type, of which there
are four different occurrences:
Fare structure " Distance-based fare"
Distance-based fares are used to model fares, which directly depend on the distance covered.
"Distance" however, does not mean the link length or the line route length itself. In fact, the
calculation of a distance-based fare is based on the number of fare points on the considered
path. The number of fare points is a property of the links and time profile items. Because,
compared to the length, this attribute is TSys-specific on links, you can allocate a different fare
to the traversing of a link for different PuT-TSys.
Transport system-
specific
supplements
Supplements are defined separately per ticket type for each PuT transport
system and include the following components:
Distance-based supplements
Like distance-based fares, these are based on fare points.
Fixed supplements. These can be charged per path leg or once per transport
system or only for the TSys with the highest rank.
Fare component Description
551 PTV AG
The traversed fare points of the links and time profile items of the path are summed up, and the
fare is looked up in the table of the fare items.
The fare between two consecutive fare items can be interpolated to model a linear course.
A distance-based fare is not applicable, if the fare stage does not offer a fare for the
determined number of fare points, but is "empty".
Example: Fare structure " distance-based fare"
Let's look at a ticket type with the following properties:
Fare constant 10 CU for trips from 1 fare point through 5 fare points,
Fare constant 16 CU for trips from 6 fare points through 10 fare points,
linear increase of the fare from 16 CU to 24 CU between the range of 10 fare points and
20 fare points,
Fare constant 24 CU for trips through 30 fare points,
Ticket cannot be used fro trips with more than 30 fare points.
Expressed in a graph:
Illustration 185: Example for a distance-based fare with 5 fare stages
In VISUM you model this fare as the following distance-based fare stages:
Fare stages for the example on distance-based fare
Number of fare points Interpolate Fare [CU]
5 No 10
10 No 16
20 Yes 24
30 No 24
> 30 --- [Empty field]
552 PTV AG
Fare structure " Zone-based fare"
Zone-based fares are used in situations where the fare depends on the number of traversed
fare zones.
A ticket type with zone-based fare refers to a specific fare zone type. Not all fare zones play a
general role for the tickets, but only those whose "type" corresponds to the fare zone type of
the ticket. This is how you can especially model independent fare zones belonging to different
fare systems, which can still overlap in space.
A zone-based ticket is by default only applicable for paths which completely run over stops,
which belong to fare zones of the fare zone type of the ticket type. To replicate the calculation
logic up to and including VISUM 11, you can optionally ignore stops without fare zone. For the
creation of new models, this setting however is not recommended.
A stop can lie in several fare zones and one fare zone generally has several stops. However,
it is often clear which fare zones the passenger traverses on his path. This results in the
number of fare zones and thus the fare. With more complex covering of fare zones there are
several possibilities of covering a path through fare zones. VISUM then selects the minimum
number of covering fare zones and thus the most inexpensive fare.
A zone-based fare is still not applicable, if the fare stage does not offer a fare for the
determined number of fare zones, but is "empty".
Fare zones do not all have to be equivalent, but can be included with a cardinality into the
count. To do so, select a numeric, integer attribute and allocate the required values. A city
center zone counts twice in many fare systems for example. It then has to receive cardinality
two.
Initial fare zones and end fare zones of a path can explicitly be excluded from the application
of cardinality.
You can specify the method of counting fare zones which have been traversed on a path
several times. Either each traversed fare zone is counted exactly once, or each entering into
a fare zone causes it to be counted again.
Example: Fare structure " Zone-based fare"
553 PTV AG
Illustration 186: Example for a zone-based fare with three covering fare zones and six stops.
The fare zones in this example have different cardinalities - fare zone 2 is to be counted twice:
The following base fare is charged for the respective fare zones:
The result being, the traversed fare zones and thus also the fare for all the paths in the example
network:
Fare zone Cardinality
1 1
2 2
3 1
Number of fare zones Base fare [CU]
1 2.00
2 3.00
3 3.50
> 3 4.00
Path Traversed fare zone
numbers
Number of counted fare zones
(considering the cardinalities)
Base fare
[CU]
Stop 1 - Stop 2 1 1 2.00
Stop 1 - Stop 3 1 1 2.00
Stop 1 - Stop 6 1 and 3 2 3.00
554 PTV AG
Fare structure" From-to zone-based fare"
From-to zone-based fares illustrate a matrix fare between fare zones. The fare thus only
depends on the start and end fare zones of the path. En route traversed fare zones do not play
a role.
You can generate a complete fare matrix between all fare zones. From-to zone-based fares
are also suitable for the definition of exceptions: If trips from or to specific fare zones underlie
a different fare structure, you can define the fares of these relations with a From-to zone-based
fare, which exceed the standard ticket type by its rank.
A From-to zone-based fare is not applicable, if the matrix for the pair of start and end fare zone
of the path does not have an entry.
To define a fare from a fixed fare zone x to all other fare zones, you can create an entry for the
fare zone numbers (x, 0), thus using the value 0 as a wildcard for the end fare zone. Analog
entries for (0, y) are possible. Specific entries overwrite general entries, this means a fare
defined for (x, y) applies to trips from fare zone x to fare zone y, independent of whether fares
for (x, 0), (0, y) or (0, 0) also exist.
If the start stop or the end stop of the connection lie within more than one fare zone, several
fare zone pairs have to be considered; the fare is then defined as a minimum of all entries.
Example: Fare structure " From-to zone-based fare"
For the example in illustration 186, the following From-to zone-based fare can be modeled as
an alternative to the zone-based fare:
A comparison with the zone-based fare defined above gives the following differences:
The fare does no longer depend on the exact course of the path; a comparison between
direct and indirect path from stop 1 to stop 6 is no longer possible here, see cell (*).
However, different fares can be determined for paths with an identical number of fare
zones if required - these fares can even be asymmetrical. For example, trips from fare
zone 3 to fare zone 1 could cost 2.80 CU instead of the standard fare for two fare zones.
Only the entry at position (3, 1) would have to be changed. This could not be expressed
in a zone-based fare.
The above matrix can be modeled in VISUM as follows:
Stop 1 - Stop 4 1 and 2 3 3.50
Stop 1 - Stop 5 via 3 and 4 1 and 2 3 3.50
Stop 1 - Stop 5 directly via 2 1 and 2 or 1 and 3 2 (for the path through 1 and 3) 3.00
Stop 1 - Stop 6 via 2, 3, 4, 5 1 and 2 and 3 4 4.00
to fare zone
from fare zone
1 2 3
1 2.00 3.50 (*) 3.00
2 3.50 3.00 3.50
3 3.00 3.50 2.00
from FZ to FZ Fare [CU]
555 PTV AG
The last entry is a wildcard for all fare zone pairs which were not mentioned explicitly before.
You can also express, that the ticket type is not applicable for certain pairs of fare zones:
According to this definition, the ticket cannot be used for all trips to the new fare zone 4 - but
for trips in the opposite direction, for the fare of 2.70 CU.
Fare structure " Short-distance fare"
The short-distance fare is a standard fare for trips below certain threshold values for run time,
trip distance and/or number of stops. Short-distance fares can therefore only be applied to
paths which meet these threshold values.
A short-distance ticket type can also contain more than one set of threshold values (short-
distance fare items). You can express for example, that there are specific fares for certain run
times, for example 1 CU up to 10 min, 2 CU up to 30 min, etc.
A short-distance ticket is applicable, as soon as the threshold values of at least one of its fare
items are fulfilled. The fare is defined as the minimum fares of all fare items, whose threshold
values are met.
Example Fare structure " Short-distance fare"
Fare item 1: Trips to the next stop only cost 0.50 CU:
Fare item 2: as above, but only for trips with a maximum of 5 min run time. The fare is then only
0.30 CU.
1 1 2.00
2 2 3.00
3 3 2.00
1 3 3.00
3 1 3.00
0 0 3.50
from FZ to FZ Fare [CU]
4 All 2.70
All 4 [Empty field]
max. run time unlimited
max. distance unlimited
max. number of stops 1
Fare 0.50 CU
max. run time 5 min
max. distance unlimited
max. number of stops 1
Fare 0.30 CU
556 PTV AG
The fare for fare item 2 can in principle also be selected higher than the fare for fare item 1.
This however, would not be reasonable because for trips up to the next stop with maximum 5
minutes run time, both threshold values are met, i.e. the fare is the minimum of both fares. This
minimum would then be 0.50 CU, the second fare item therefore ineffective. This is an example
for the following aspect:
Consistency of fare stages
The fare stages of a ticket type (more precisely the fares at the fare items of the ticket type) can
be freely defined. In principle this also makes contradicting entries possible. For example, the
fare for a greater distance can be smaller than the fare for a shorter distance, or a short-
distance fare for a trip up to three stops can be more expensive than a short-distance fare for
up to five stops. It is recommended however, that such contradicting definitions should be
avoided.
7.5.2.2 Initial fare and transfer fare
In the standard case, all fare systems are independent, so that the total fare for a connection
is the sum of fares per fare system. Transfer fares allow modeling of interactions. These are
added together with the initial fare to the base fare.
The initial fare is only imposed for the first path leg and depends on the fare system of the first
path leg. The transfer fare is calculated for each transfer, where a new ticket has to be bought.
It depends on the fare systems of the lines, where the transfer is made.
Both components can be negative for modeling deductions. The resulting total fare of a
connection is however greater or equal to zero.
Example: Start and transfer fares (see ""Fare-reference" of a fare system" on page 560)
7.5.2.3 Transport system-specific supplements
Each ticket type has its own supplement regulations. These include PuT transport system
distance supplements and fixed supplements, whereas for the latter a transport system rank
can also be set. Furthermore, you can define a minimum fare for each transport system.
Supplements are imposed for each application independently. This also applies, when the
same ticket type is bought several times on one connection.
You can define supplements for all PuT transport systems of the network in each ticket type.
Of course, only the settings for those transport systems, whose lines are connected with the
fare system of the ticket type are effective, which means for passengers are able to use the
ticket type in the first place.
Minimum fare
The minimum fare for each transport system is charged instead of the calculated total fare for
the ticket type, in case
the transport system appears on the path legs covered by the ticket and
the total fare is less than the minimum fare.
The minimum fare is therefore not a component which can be added, but a minimum value for
the total fare which has to be charged. Because the regulation applies for all transport systems,
the maximum minimum fare of all occurring transport systems, is the lower limit for the total
fare of the ticket type.
557 PTV AG
Further down you will find a simple example on minimum fares (see "Example: Calculation of
fixed supplements" on page 557).
Fixed supplements
Fixed supplements are constant additional charges which are added to the base fare of the
ticket type. Each PuT transport system has its own fixed supplement. For which of the path
legs covered by the ticket type, a fixed supplement can be imposed, is a central feature of the
ticket type. Select one of the following options:
Raise supplement once per transport system,
Raise supplement only for the top-ranking transport system,
Raise supplement per path leg.
In the first case, exactly one fixed supplement is incurred for each occurring transport system
- independent of how many path legs are being used with lines of the transport system.
In the second case, the ranks of the transport systems from the supplement regulations of the
ticket type, play a role. Using the ranks, you can express that a certain transport system (e.g.
ICE) discharges the passenger from paying fixed supplements for other transport systems
(e.g. IC). If several transport systems have the same rank, on the path legs covered by the
ticket type, the maximum fixed supplement of the top-ranking transport system applies. Ranks
do not influence distance-based supplements.
In the third case, a fixed supplement is imposed for each path leg anew, for the transport
system used.
The difference between the three options for imposing fixed supplements can be made clearer
with the following example:
Example: Calculation of fixed supplements
These are the following distance-dependent supplements for the ICE:
The considered calculation contains four path legs: IC, RE, IC and ICE. The following tables
show the calculation of the fare for the three different options for imposing fixed supplements:
Transport system Fixed supplement
[CU]
Minimum fare [CU] Rank Distance-based
supplement
IC 4.00 0.00 2 No
ICE 0.00 7.00 1 Yes
RE 0.00 0.00 3 No
Number of fare points Fare [CU]
50 0.50
100 1.00
200 2.00
300 3.00
400 4.00
500 5.00
600 6.00
> 600 7.00
558 PTV AG
1. Supplement once per transport system:
(*) 0.00 CU, because the IC supplement was already imposed on the first path leg.
(**) 0.50 CU both for additive and proportional calculation of the distance supplement
(see "Distance-based supplements" on page 559).
(***) The minimum fare of 7.00 CU no longer has an effect, because the regular fare of
8.50 CU is higher.
2. Supplement only for the top-ranking transport system:
(*) Only the fixed supplement of the top-ranking transport system (ICE) is obtained,
even if in this case it is 0.
(**) The ICE minimum fare is imposed, because the ICE is used and the regular fare of
4.50CU is lower than the ICE minimum fare.
3. Supplement per path leg:
(*) Different than in the first case, reimposition of fixed IC supplement.
Path legs of the
connection
Fare points Base fare [CU] Fixed
supplement
[CU]
Distance
supplement
[CU]
Minimum fare
[CU]
IC 50 4.00 0.00 0.00
RE 200 0.00 0.00 0.00
IC 100 (*) 0.00 0.00 0.00
ICE 50 0.00 (**) 0.50 (***) 7.00
Total 400 4.00 4.00 0.50
Total fare 8.50
Path legs of the
connection
supplement
[CU]
Distance
supplement
[CU]
Minimum fare
[CU]
IC 50 (*) 0.00 0.00 0.00
RE 200 0.00 0.00 0.00
IC 100 (*) 0.00 0.00 0.00
ICE 50 0.00 0.50 7.00
Total 400 4.00 0.00 0.50
Total fare (**) 7.00
Path legs of the
connection
supplement
[CU]
Distance
supplement
[CU]
Minimum fare
[CU]
IC 50 4.00 0.00 0.00
RE 200 0.00 0.00 0.00
IC 100 (*) 4.00 0.00 0.00
ICE 50 0.00 0.50 (**) 7.00
Total 400 4.00 8.00 0.50
Total fare 12.50
559 PTV AG
(**) The minimum fare of 7.00 CU no longer has an effect, because the regular fare of
12.50 CU is higher.
Distance-based supplements
Each PuT transport system has its own fare stage for distance-based supplements. They are
calculated exactly like distance-based base fares, therefore based on the number of fare
points. The number of fare points for each transport system, is only summed up across those
path legs which belong to lines of the transport system. Distance-based supplements are also
added to the base fare of the ticket type.
There are two variants, on how distance-based supplements can be read from the fare table of
the distance stages:
proportional calculation
additive calculation
This setting is a ticket type property. For proportional calculation, the distance supplement valid
for the sum of fare points over all path legs is taken from the fare table and then multiplied with
the relative proportion of fare points of this transport system. The additive calculation is easier
- the distance supplements for the number of fare points of the transport system are directly
imposed for each transport system.
The following calculation example compares the two options:
Example: Calculation of distance-based supplements
On a connection, 100 fare points are traversed using ICE and 50 using IC. The distance-based
supplements are as follows:
Distance supplement for proportional calculation:
Distance supplement for additive calculation:
7.5.3 Fare systems
A fare system is a set of lines which have the same fare logic. In principle the passenger can
therefore use these lines with one ticket. A fare system could for example be an individual
operator or a transport association.
One or more ticket types are allocated to each fare system for each PuT demand segment.
Example: Fare systems, ticket type and demand segments
Number of fare points (FP) ICE supplement [CU] IC supplement [CU]
<= 50 3.00 2.00
<= 100 4.00 3.00
<= 150 5.00 3.50
FP
ICE
FP
ICE
FP
IC
+
----------------------------------- Supplement
ICE
FP
ICE
FP
IC
+ ( )
FP
IC
FP
ICE
FP
IC
+
----------------------------------- Supplement
IC
FP
ICE
FP
IC
+ ( ) +
100FP
150FP
----------------- = 5 00CU ,
50FP
150FP
----------------- 3 50CU , + 4 50CU , =
Supplement
ICE
FP
ICE
( ) Supplement
IC
FP
IC
( ) + 4 00 CU ( ) 2 00 CU ( ) , + , 6 00CU , = =
560 PTV AG
There are two demand segments which model whether a monthly pass is in possession or not.
This differentiation is made in advance on the demand segment level, because purchasing a
monthly pass is a long-term decision and not just when selecting the concrete connection.
There are three fare systems in the example: City, Metro and Rail long-distance. The three fare
systems are completely impartial for passengers without a monthly pass, where there is a
normal ticket and a short-distance ticket (with different properties) for both City and Metro.
Monthly pass buyers are, however, offered the same ticket for City and Metro.
Using the VISUM demand segments, it is defined which PuT users are allowed to use which
ticket types in which fare system. The following table provides an overview:
The fare system rank plays a role when lines belong to several fare systems, as can be seen
in several examples subsequently (see "Procedure for ambiguous fare systems" on page 563).
7.5.3.1 " Fare-reference" of a fare system
The most important fare system property is determining how far an individual ticket is valid.
This may be an individual path leg, i.e. a new ticket has to be bought for each boarding. A
second possibility would be that a ticket is valid for successive path legs within a fare system,
and a new ticket only has to be bought when leaving the fare system and entering it again.
Thirdly, a ticket may be valid for all path legs of a connection, which belong to the same fare
system - even if path legs of other fare systems lie in between. All three cases are practice-
related.
The central fare system attribute Fare-reference is used to model this aspect and can assume
one of the following values:
Each path leg separately: A ticket has to be bought for each path leg of the fare
system.
Each group of contiguous path legs: A ticket has to be bought for each group of
contiguous path legs of a fare system.
All path legs together: For all path legs together, i.e. for the whole trip, one ticket is
sufficient for this fare system.
Path legs which belong to another fare system, can never be used with the same ticket.
Example: Fare system properties " Fare-reference"
We are looking at a connection with four path legs, with transport systems Bus Tram Train
Bus. Using the above example of the three fare systems: Bus and Tram belong to the same
DSeg "Passengers without a monthly
pass"
DSeg "Passengers with a monthly pass"
Fare system City
(Bus, Tram)
Regular fare City (a Zone-based
fare),
Short-distance City (max. 10 min)
Monthly pass region
Fare system
Metro
Normal fare metro
(a distance-based fare),
Short-distance Metro (max. 3 stops)
Monthly pass region
Fare system Rail
long-distance
Single ticket rail Monthly pass rail
Table 205: Linking fare systems and demand segments
561 PTV AG
fare systems City, the same ticket types are therefore valid. The transport system Train
belongs to the fare system Rail.
To keep the example simple, let's assume the following ticket types:
Normal fare City: 100 CU for all distances.
Short-distance City: 60 CU for all trips up to max. 10 min. In the example, only the trip
on the first bus is shorter than 10 min.
Normal fare Rail: 200 CU for all distances.
Even if the fare structure has been simplified, this example clearly shows, how the total fare
changes subject to the fare-reference. The following fares for the connection apply for each
fare-reference:
In the first case the passenger pays for each path leg in the fare zone "City" individually
and only for the first path leg is he allowed to use the short-distance ticket, because all
other path legs have an operating time of more than 10 minutes.
In the second case the successive path legs 1 and 2 can be used with the same ticket.
Only in the third case do you only pay once for the entire fare zone "City".
The third path leg is ignored, because the "Train" belongs to a separate fare system.
The example of start and transfer fares are supplemented:
Example: Fare-reference and start and transfer fares
Both fare zones therefore require a initial fare as a base value at trip start. Transfers within the
same fare system cost in the case of "City" an additional charge of 50 CU, in the case of "Rail"
nothing. For a transfer from "Rail" to "City" an additional 80 CU is charged, vice versa however,
there is a reduction of 20 for a transfer from "City" to "Rail".
The following table displays the start and transfer fare, which are added to the base fares listed
above:
Fare applies to...
Path leg -
TSys
Fare system Each path leg
separately
Each group of
contiguous path legs
All path legs together
1 Bus City 60
(Short-distance) 100
100
also includes bus
at the end
2 Tram City 100
3 Train Rail 200 200 200
4 Bus City 100 100 no extra fare
Fare sum 460 400 300
Supplement / deduction FS City FS Rail
Initial fare 100 200
Transfer fare from FS City to 50 -20
Transfer fare from FS Rail to 80 0
Fare applies to...
562 PTV AG
Even if the example is simple, you can see what great influence the "Fare-reference" has on
the fare calculation and thus on the fare itself. It is therefore very important to define it
according to the real fare conditions of the modeled network.
7.5.3.2 Ticket selection in a fare system
In reality the ticket can not always be selected freely even if in principle several ticket types
can be applied because there is usually a predefined order. This order is modeled in VISUM
by the rank of ticket types. It defines the hierarchy of the ticket types within the fare system.
Taking the above example (see "Short overview" on page 546) let's look at the case of an
individual fare system, which has three different ticket types:
1. Fare condition descriptions:
2. Modeling in VISUM:
To model these fare conditions, the three ticket types have the following properties:
The airport ticket has the highest rank (for example 1), because it has to be used in all
cases where it can be applied (for all trips from and to the airport)
The airport ticket is a From-to zone-based fare, because the fare only depends on initial
fare zone and target fare zone of the connection. In this fare matrix however, only those
Path leg -
TSys
Fare system Each path leg
separately
Each group of
contiguous path legs
All path legs together
1 Bus City 100
100
100
also includes bus
at the end
2 Tram City 50
3 Train Rail -20 -20 -20
4 Bus City 80 80 no extra fare
Sum of start
and transfer
fares
210 160 80
Fare sum
(see above)
460 400 300
Total fare 670 560 380
1 Normal fare The fare of the ticket type depends on the number of traversed fare zones as
follows:
1 fare zone: 2.00 CU
2 fare zones: 3.00 CU
3 fare zones: 3.50 CU
4 or more fare zones: 4.00 CU
2 Airport ticket All trips into or out of the special zone Airport are subject to a exception. They
constantly cost 3.75 CU, independent of the fare zone at the other end point
of the path.
3 Short-distance
fare
For all trips up to ten minutes run time, a short-distance ticket can be used for
the fare of 1.00 CU. These do not include trips from or to the airport.
563 PTV AG
relations whose start or destination fare zone is the airport, are occupied. Other entries
do not exist, which shows the restricted applicability.
The short-distance ticket has the next higher rank (for example 2), because for all trips
outside of the airport, it is always bought when it is applicable. A maximum duration of
10 minutes is stipulated. There are however no threshold values for trip distance or
number of stops.
The normal (zone-based) fare has the lowest rank (for example 3). In principle the ticket
can always be used, because the number of traversed zones provides a definite fare.
The lower rank however, forces this ticket not to be used in the special cases airport trip
or short-distance, but one of the other two.
3. Examples for paths in this fare system (and its fares):
A trip over 20 minutes from fare zone city center to fare zone sports field leads through
another fare zone university. These are three fare zones, the fare costs 3.50 CU.
A trip over 8 minutes leads from fare zone city center to fare zone university. A short-
distance ticket applies, the trip costs 1.00 CU.
A trip over 7 minutes and another over 12 minutes leads from fare zone university to
fare zone airport. In each case the airport ticket for 3.75 CU applies.
A trip within the fare zone also costs 3.75 CU.
A trip over 45 minutes from fare zone university via fare zone airport leads to fare zone
industrial park. The airport is not start or destination fare zone, the normal fare for three
fare zones (3.50 CU) therefore applies.
7.5.4 Fare calculation
The total fare of a PuT connection is generally equal to the sum of fares for the individual fare
systems, which occur on this path. Interactions can only be considered through transfer fares
(see "Initial fare and transfer fare" on page 556).
Decisive is "those which occur on this path". If the fare system per path leg is clear, i.e. each
used line (or the PuT supplement transport systems) belongs to exactly one fare system, fare
calculation is split into separate blocks and the calculation within a block is carried out as
described before (see "Ticket selection in a fare system" on page 562).
This is also the case for the above example on "fare-reference", because the fare for the train
line is completely independent of the fare calculation for the other three path legs (see
"Example: Fare system properties "Fare-reference"" on page 560). In such a simple situation,
there is only one possible fare system combination, in step 1 of the algorithm on fare
calculation (see "Algorithm on fare calculation" on page 566).
The general case of several possible fare systems per path leg, however, requires an
extension of the previously described modeling:
7.5.4.1 Procedure for ambiguous fare systems
If lines belong to several fare systems, many possibilities will potentially occur for the selection
of fare systems (and therefore tickets) on a connection. The following examples show typical
situations, where such multiple-allocation is necessary.
To systematically compare and determine all possibilities, fare systems also receive ranks,
which expresses a specified order. First however, an example which does not need any ranks:
564 PTV AG
Example: Fare calculation for ambiguous fare systems, trip to C Town, part 1
Let's consider the following path legs:
It is assumed, that on the middle path leg both City and Rail ticket types can be used, in
particular all stops up to and including B Town belong to fare zones of the fare system City.
The total path can therefore be used in two different ways (fare systems City-City-Rail or fare
systems City-Rail-Rail), and the passenger selects the inexpensive one of the two.
Note: In each of the two variants the regional train ticket may also apply for the path leg directly
before or after the used line exactly then when the "fare-reference" of your fare system (City
or Rail) is "Each group of contiguous path legs" or even "All path legs together". This aspect is
however, not subject of the example
If no ranks are assigned to the fare systems, all fare systems have the default rank 1, and there
is no hierarchical order. All possibilities have to therefore be examined and the most
inexpensive used, which is what this example wants.
Example: Fare calculation for ambiguous fare systems, trip only to B Town
Let's now look at the case, that the trip already ends in B Town:
The validity range of the fare system City is not left and we assume, that the regional train in
this case, is only allowed to be used with tickets from this fare system. This even applies, if it
were more inexpensive to buy a Rail ticket from the main station.
To model this ranking in VISUM, the fare system City must have a higher rank (for example 1),
than the fare system Rail (for example 2). Within the fare calculation the fare systems are
regarded in descending rank order and the highest ranking used, which is applicable. Because
for the rank 1 fare system a valid ticket already exists in this example, the rank 2 variant is not
even reviewed.
What does this definition of ranks now imply for the previous example, where explicitly both
fare systems could be applied for the regional train line?
From To Line (TSys) Fare system
A Town bus terminal A Town main station Bus 42 (Bus) City
A Town main station B Town Regional train City or Rail
B Town C Town Intercity Rail
From To Line (TSys) Fare system (with rank)
A Town bus terminal A Town main station Bus 42 (Bus) City (#1)
A Town main station B Town Regional train City (#1) or Rail (#2)
A Town main station B Town Regional train City (#1) or Train (#2)
B Town C Town Intercity Rail (#2)
565 PTV AG
Compared to the case, that the trip ends in B Town, it is not possible to use the entire
connection within the prior-ranking fare system City, because the intercity to C Town is not
included. A rank 2 fare system is therefore inevitable on this path. This is the starting point for
a definition of ranks of fare system combinations, which enable maximum flexibility when
modeling such fare conditions.
In the example, fare system combinations City-City-Rail and City-Rail-Rail are possible. Their
ranks are the same, because max {1, 1, 2} = 2 and max {1, 2, 2} = 2. That is why none of the
two are prior-ranking; the passenger in the regional train is therefore not fixed to the fare
system City.
By allocating rank 1 for fare system City and rank 2 for fare system Rail, it was overall achieved
that the regional train within the City network can only be used with City tickets, but for trips
across the network boundaries, it can also be used within the Rail fare system.
Let's now look at the variant, that the regional train itself goes to C Town:
In this case it looks as if exactly like for trips to B Town the exclusive use of the City fare
system is forced. However, this only applies if the City ticket can be bought up to C Town, if
therefore all stops including C Town lie within fare zones which belong to the zone-based fare
of the City fare system. If this is not the case, the attempt to use the connection with fare
systems of rank 1 fails, and fare system Rail is applied on the second path leg.
This makes it clear, that the affiliation of a line not automatically indicates, whether it can be
used on its entire itinerary with tickets of this fare system. An even clearer example is the
following:
Example: Fare network with train fare system in the background
1. Description of the network and the fare conditions:
The rank of a combination of fare systems T = {t1
, t
2
,, t
n
}
is defined as the maximum rank
of one of its fare systems: Rank(T) := max
i
Rank(t
i
).
With this specification one obtains an order on the set of all fare system combinations.
Combinations of the same rank count as being equal. This means in the course of fare
calculation, VISUM regards all of them and selects the most inexpensive total fare. Only if
there are no valid combinations for a rank, will the combinations of the next lowest rank be
considered.
The global fall-back fare is only applied if no valid combination exists. This can be assigned
with a value such as -1, to easily identify paths without valid ticket(s) after an assignment. If
fares incur an assignment in the impedance definition, please note that a higher fall-back fare
(e.g. 99999) prevents paths without a valid ticket(s) from being found and loaded.
A Town main station C Town Regional train City (#1) or Rail (#2)
566 PTV AG
A regional train line traverses the range of four fare systems (networks), which all together are
zone-based fare systems. There are spatial overlaps between the first and the second as well
as the second and the third.
For trips on the regional train line within a fare system, ticket types of this fare system are
mandatory. This also applies, if parts of the fare system area are traversed, which cover a
different fare system. For trips across the boundaries of a fare system, however, ticket types of
the fare system Rail long-distance definitely have to be used.
This regulation still leaves the open question, which ticket type to buy, if one entirely travels in
the covered section of two fare systems. The following regulation applies in this situation: In the
covered sections of fare system 2 with fare system 1 and with fare system 3, the latter has
precedence.
2. Resulting modeling of the ticket type in VISUM:
Because the line can at least be partially used in all five fare systems, it has to be allocated to
all fare systems. To express the precedence of fare systems 1 and 3 against fare system 2 in
the covered sections of the fare zones, both must have a higher rank (for example 1), than fare
system 2 (for example 2). The rank of fare system 4 is not important, it can be set to 3. The non
zone-based fare system 5 (Rail long-distance) must have the lowest rank (for example 5),
because each of the four zone fare systems have precedence, if a trip takes place within it.
These ranks have a desired effect on the selection of the ticket type(s) through the following
model:
Each zone-based fare system has a specific fare zone type, for example 1, 2, 3 and 4, and
corresponding ticket types with fare structure zone-based fare. The spatial overlap of zone fare
systems arises in the overlap of their fare zones. All stops served by the line, thus lie exactly in
one fare zone or in two fare zones of different types.
This is how you achieve, that each of the zone-based ticket types can only be used, if all
traversed stops lie within fare zones which belong to the fare system of the ticket. Two ticket
types can only be used in the covered range of the fare systems and there the fare system
ranks provide specified preference. The fare system "Rail long-distance" is used as a fall-back,
because a valid ticket can be bought for this one in any case.
7.5.4.2 Algorithm on fare calculation
The succession of all decisions which lead to the selection of the ticket(s) used on a path, can
be formulated as an algorithm. This particularly clarifies the meaning of the ranks for fare
systems and tickets.
567 PTV AG
Each path consists of a sequence of path legs. Each path leg has one PuT line which is
connected to one or more fare systems (or a PuT-Aux transport system which is also allocated
to fare systems). The algorithm on fare calculation is as follows:
1. Determining fare systems:
Go through all possible fare system combinations for the different path legs, i.e. in
descending ranking order (whereas Rank of the combination = Maximum rank of the fare
systems in the combination). Calculate the fare for each combination according to step 2.
Select the lowest fare from the fare system combinations of the same rank. If all fare
systems of a rank are invalid, consider the combinations of the next rank. If there is no valid
fare system combination, the global fall-back fare applies.
2. Analysis of a fare system combination:
If fixed fare systems are provided for all path legs, iterate over all fare systems used and
calculate their fares according to step 3. If all calculations lead to a valid fare, the sum is a
valid fare for the total path. If not, this fare system combination is invalid.
3. Consideration of a fare system on all path legs allocated to it:
According to the fare system attribute Fare reference, determine for which subsets of the
fare system path legs separate ticket types have to be used. Iterate over all these path leg
subsets and calculate their fares according to step 4. If all calculations supply a valid fare,
the sum is a valid fare for the fare system. If not, fare calculation for this fare system fails.
4. Consideration of a fare system of a path leg subset:
For a fare system and a predefined path leg subset, iterate over all ticket types which are
used by the fare system, in descending order. Calculate the fare for each ticket type
according to step 5. From the ticket types of the same rank, select the one with the lowest
fare. If all ticket types of a rank cannot be used, consider the ticket types of the next rank.
If there is no applicable ticket type, the fare system is not permitted on this path leg subset.
5. Consideration of a ticket type on a path leg subset:
Calculate the base fare according to the fare structure of the ticket type (Distance-based
fare, Zone-based fare, From-to zone-based fare, Short-distance fare). If the fare table does
not contain a valid entry, the ticket type cannot be applied. Add up the initial fare for the first
path leg of the path. Add up the transfer fare according to the fare system which was used
on the preceding path leg.
Determine and add up the distance-based supplement for the number of fare points
counted. If the table does not contain a valid entry, the ticket type cannot be applied.
Determine and add up the fixed supplement. Compare the total fare with the minimum fares
of all occurring transport systems and raise it if necessary.
7.5.5 Application of fares
With the fare model, fares can be included in the timetable-based assignment in the
impedance of a connection and thus have influence on the connection choice. This does not
apply for the headway-based assignment, because route choices are not made between
complete connections, but for each boarding and transfer decision. This is a basic
characteristic of this family of assignment procedures and cannot be avoided due to
methodical reasons. Linear dependency of the fare from the (measured in fare points) covered
distance can still be modeled in the headway-based assignment, because the number of fare
568 PTV AG
points is included directly in the impedance and furthermore boarding penalties and transfer
penalties can be allocated.
The following skim matrices can be derived from both PuT assignment types:
Fare
Number of traversed fare zones
Please note that the skim "Number of fare zones" only counts those fare zones, which are
relevant for determining the fare. If a ticket has priority (or is cheaper with the same rank),
which has a different fare structure other than a "zone-based fare", fare zones on path legs of
this ticket do not play a role and are not counted for the skim. This is necessary, because
several fare zone systems, separated by type, may exist next to each other and each ticket
type applies to fare zones of one type at the most. "The" number of fare zones does not exist.
After an assignment you can access the ticket type used for each path leg, via the " PuT path
legs" list and analyze both the fare and the revenue for each path leg.
The difference between fare and revenue is, that fares always refer to the VISUM fare model,
revenues however can be calculated alternatively as a fixed revenue per passenger trip or as
a revenue per fare point.
Fares from the fare model can also be used as input data for Revenue calculation within the
PuT operating indicators (see "Revenue calculation using the fare model" on page 597).
7.6 PuT Operating Indicators
Line costing calculations are based on operational indicators. They can be divided into the
following categories:
General indicators
Indicators for the measurement of transport supply
Indicators for the measurement of transport performance
Indicators for the calculation of operating costs
Indicators for the calculation of fare revenues
Indicators for vehicle requirement and line blocking (see "Line blocking" on page 500).
The indicators are described in the indicator categories. Which network objects the indicators
can be calculated for, can be taken from the file IndicatorAvailability.xls in the directory
...\VISUM115\Doc\Eng of your VISUM installation.
Dependent on the indicator, different procedures have to be carried out, to calculate the
indicator values. Some indicators are already available after a PuT assignment, others after
the procedure PuT operating Indicators has been executed with certain settings. Furthermore,
it also depends on whether indicators are calculated on the line hierarchy or for territories. An
overview of this dependency you can find in the file IndicatorSource.xls in the directory
...\VISUM115\Doc\Eng of your VISUM installation which provides the following details: Which
procedure has to be used for which indicator and which settings have to be made for the
calculation. Basically, the following procedures are relevant for the calculation:
PuT Operating Indicators
Territory indicators
PuT assignment
569 PTV AG
Chapter 7.6: PuT Operating Indicators
Line blocking
The indicators are basically calculated for analysis period, analysis horizon and analysis time
intervals (provided that analysis time intervals are defined). There are however exceptions,
where there is no calculation for analysis time intervals. This is characterized in the indicator
table (IndicatorAvailability.xls) as follows:
AHP = available for analysis period and analysis horizon
AHPI = available for analysis time intervals, analysis period and analysis horizon.
X = indicator is available, but does not show a time reference
7.6.1 Demonstration example
The following example Example_LLE.ver (illustration 187) is used to illustrate the indicator
calculations. The description of the indicator categories pick up this example again. You can
find the example file in the directory ...\VISUM115\Examples\Example_Net\.
Illustration 187: Example network with two lines and volume data
Transport Supply
The transport system of the demonstration example consists of two lines with two line routes
per line (outward and return line routes), but partially shortened trips.
Line Orig.
Stop
Dest.
Stop
Length
[km]
First
dep.
tCur
[min]
Last
dep.
Run
time
[min]
Number
of trips
Valid Day
BUS > 10 40 27.5 06:07 00:40 18:07 00:45 19 daily
Table 206: Transport supply in Example_LLE.ver
570 PTV AG
Projection factors and analysis time slices
The model contains an analysis time period TI1 for the traffic during morning peak hours (8
a.m. to 9 a.m.). The projection factors on the analysis horizon on the valid days are assigned
respectively (see User Manual, Chpt. 2.41, page 550).
The projection factor for demand segment PuT is allocated as follows.
Vehicles used
Fare Model
The fare model includes two fare zones, which have been assigned the following stops.
BUS < 40 10 27.5 06:02 00:40 18:02 00:45 19 daily
BUS > 30 40 7.5 05:37 00:40 17:37 00:13 19 weekdays
BUS < 40 30 7.5 06:29 00:40 18:29 00:13 19 weekdays
TRAIN > 20 40 10.0 06:29 00:40 18:29 00:16 19 daily
TRAIN < 40 20 10.0 06:09 00:40 18:09 00:16 19 daily
Valid Day Proj. factor transport supply Proj. factor hourly costs
daily 365 365
weekdays 260 260
Table 207: Projection factors for the valid days in Example_LLE.ver
Demand segment Projection factor
PuT 365
Table 208: Projection factor for the demand segment
Vehicle type SeatCap Total Capacity
Standard bus 35 90
Low floor bus 35 50
Train 200 400
Table 209: Total capacity provided in the vehicles of example Example_LLE.ver
Number Name FZ100 FZ200
10 A Village X
20 C Village X
30 B Village X X
40 X City X
Table 210: Fare model in Example_LLE.ver
Line Orig.
Stop
Dest.
Stop
Length
[km]
First
dep.
tCur
[min]
Last
dep.
Run
time
[min]
Number
of trips
Valid Day
Table 206: Transport supply in Example_LLE.ver
571 PTV AG
Stop 30 (B village) is located exactly between fare zones FZ100 and FZ200, and is therefore
assigned to both fare zones.
Tickets and Fares
Additionally, a supplement of 3.00 CU (currency units: for example, Euro, Pound, Dollar) is
required for each rail ticket.
Transport demand
Table 212 displays the number of passengers between the zones.
Cost rates
Link costs
Track charge of 100 CU/km on railway track between stop 20 and stop 40, plus
depreciation charge of 100000 CU. All other links have a utilization fee of 10 CU/Km and
running costs of 20 CU in the analysis horizon.
Vehicle costs
Fare zones One-way ticket [CU] Four-trip ticket [CU] Monthly pass [CU]
One-way fare Fare One-way fare Fare One-way fare
up to 2 fare zones 1.00 3.20 0.80 60.00 1.50
up to 3 fare zones 2.00 6.40 1.60 60.00 1.50
up to 4 fare zones 3.00 10.40 2.60 60.00 1.50
as of 4 fare zones 5.00 12.00 3.00 80.00 2.00
Table 211: Fares of the fare model in Example_LLE.ver
FromZone ToZone Line1 Line2 Demand
A Village X City Bus1 Train 2000
X City A Village Train Bus1 2000
A Village C Village Bus1 200
C Village A Village Bus1 200
C Village X City Train 5000
X City C Village Train 5000
B Village X City Bus1 2000
X City B Village Bus1 2000
Total 18400
Table 212: Transport demand between the zones in Example_LLE.ver
Standard bus Low floor bus Train
Service Empty Service Empty Service Empty
Cost rate per hour [CU/h] 300.00 200.00 300.00 200.00 700.00 500.00
Cost rate per km [CU/km] 5.00 5.00 5.00 5.00 10.00 10.00
Table 213: Cost rates for vehicles in Example_LLE.ver
572 PTV AG
In addition, a charge of 50 CU/h is due for each vehicle combination Train.
The operator costs amount to annual administrative costs of 1000 CU for the bus operator
and 5000 CU for the train operator as well as depreciation costs of 100000 CU each.
7.6.2 Indicators for line route and timetable evaluation
The following indicators comprise line data, which are made up of the line route and the
timetable. Demand data is not required for calculation.
Cost rate per vehicle [CU/
Veh/AP]
7000.00 7000.00 20000.00
Standard bus Low floor bus Train
Table 213: Cost rates for vehicles in Example_LLE.ver
LineNetLengthDi
r
Sum of link lengths of the links traversed by line routes. Traverses a line route a link
more than once, it is only counted once.
LineNetLengthU
ndir
Compared to the directed line network length, for links which are traversed in both
directions, only the undirected values (this means, the mean value from the lengths of
both directions) is counted. If the link is only traversed in one direction, the undirected
length corresponds to the directed length.
Network length
directed
Total length of links open to transport system. The length of both directions is included
in the calculation.
Network length
undirected
Compared to directed network length, for links the average link length (this means the
mean value from the lengths of both directions) is counted for both open directions.
Num lines The meaning of this indicator depends on the network object for which it is being
calculated.
Main lines take the number of lines into consideration, which belong to the main line.
PuT operators take the number of lines into consideration, which are operated by
the PuT operator.
Blocks take the number of lines into consideration, which are traversed on a block.
Links take the number of lines into consideration, which traverse a link.
Transport systems take the number of lines into consideration, which use this
transport system.
For zones / main zones, a line is regarded, if the zone is connected to a node with
a stop point, which is traversed by the line. No line trip has to serve the stop point
Stops take the number of lines into consideration, which traverse this stop. No line
trip has to serve the stop point
Stop points take the number of lines into consideration, which traverse this stop
point. No line trip has to serve the stop point
Num lines TSys Additionally returns the number of lines for each transport system. Otherwise, the
indicator is analog to the number of lines.
Num line routes Number of line routes of a line or number of line routes run by a vehicle combination
during a block.
Stop points total Number of stop points, which lie within a territory polygon.
Table 214: Indicators for line route and timetable evaluation
573 PTV AG
Stop points
served
Number of served stop points, which lie within a territory polygon. A stop point is
served, when it is traversed by a line route. Thus, a line route item with this stop point
is required and for the respective time profile item boarding or alighting has to be
possible. It is not necessary that trips serve this stop point.
Stops served The meaning of this indicator depends on the network object for which it is being
calculated.
Territory PuT detail regards the number of served stops being located within a
territory polygon. Stops are not served, if none of the time profiles includes a stop at
one of the stop's stop points. Multiple stops within a stop are only counted once
Lines take the number of stops into consideration, which are traversed by a line.
This is independent of whether a stop at the respective stop point is intended in the
time profile or not.
Line routes regard the number of served stops, which are traversed by the line
route. This means, that stops are not served, if no time profile contains a stop at one
of the stop's stop points.
Time profiles take the number of stops into consideration, for which a stop is
intended for its stop points, in the TP.
Service trips take the number of stops into consideration, where a service trip stops.
Transport systems take the number of stops into consideration, which a transport
system traverses. This is independent of whether a stop (boarding or alighting) is
intended in the respective time profiles.
Stop events Number of stop events at stops within the territory polygon. All stop events at the
stops are counted. A trip is thus counted several times, if a trip stops at several stop
points within the stop. If a stop point lies in another territory than the respective stop,
the stop still counts for the stop in the territory. The number of stop events in the
territory counts for each service trip and is aggregated for the other levels, if
necessary. Different from the indicator "Stop points served" trips are required.
Otherwise stop events do not count.
StartStopEvents Number of service trips, which start at a stop in the territory.
EndStopEvents Number of service trips, which end at a stop in the territory.
Earliest
departure
Earliest departure from stop point located inside territory. This is the earliest departure
within the analysis time slice, not necessarily the first departure of the day (for
example, departure at 12:20 a.m.).
Latest arrival Latest arrival at stop point located inside territory. This is the latest arrival within
analysis time slice, not necessarily the last departure of the day (for example, arrival
at 11:59 p.m.).
StopTime The stop time, which accumulates from stop events at stop points within the territory
polygon. The stop time is made up of the input attribute Stop time at the time profile
items.
574 PTV AG
Num departures The meaning of this indicator depends on the network object for which it is being
calculated. The indicator is especially interesting for time interval-related analyses, to
determine the departures within a certain time interval for example.
For main lines / lines it returns the number of service trips run by this line.
For line routes it returns the number of service trips run by this line route
For time profiles it returns the number of service trips using this time profile
For PuT operators it returns the number of service trips operated by this PuT
operator
For transport systems the number of service trips operated with this transport
system
For stops, the number of service trips which stop for boarding is returned. Stop
events at several stop points within the stop are counted several times. If a stop is
traversed several times within a trip, the departures are also counted several times
For stop points, the number of service trips which stop for boarding is returned.
Num departures
TSys
Different from Num.Departures, the number of departures is returned by transport
system. Calculation is otherwise analog.
Num arrivals Number of service trips, which stop for alighting at the stop or the stop point. Multiple
stop events are counted several times for a stop.
NumArrivalsTSy
s
Different from Num.Arrivals, the number of arrivals is returned by transport system.
Calculation is otherwise analog.
575 PTV AG
Num Service
Trips
The meaning of the indicator depends on the network object for which it is being
calculated:
For territory analyses, the number of service trips traverse a territory is returned. A
service trip is added to the territory, if at least one stop of the service trip lies within
the territory The stop point location is not crucial, but the stop location.
For main lines / lines / line routes, the number of service trips by main line / line / line
route is returned
For the line route course, the number of service trips traversing the line route item
is returned (start and end stop point of the trip are decisive, it is irrelevant whether
boarding or alighting is permitted)
For time profiles, the number of service trips using this time profile is returned
For time profile items the number of service trips traversing the time profile item is
returned (crucial is the start and end stop point of the trip). It is irrelevant whether
boarding or alighting is permitted
For service trips it is specified, how often the service trip runs in the respective time
period (AH, AP, TI)
For service trip items it is returned, how often this service trip traverses the
respective service trip item (crucial are start and end stop points of the trip). It is
irrelevant whether boarding or alighting is permitted
The number of service trips run by the PuT operator is returned by operator
For blocks the number of service trips being included in the block is returned
For links, the number of service trips traversing the link is returned. A link is
regarded as if being traversed, if the service trip traverses more than 50% of the
links length
For a transport system, the number of service trips using this transport system is
returned
A service trip counts for a zone, if the zone is connected to a node with a stop point,
which is served by the service trip (boarding or alighting permissible)
For a stop, the number of service trips serving the stop for boarding or alighting is
returned. Multiple stop events at stop points of the stop are counted several times
For a stop point, the number of service trips serving the stop point for boarding or
alighting is returned
Num
ServiceTrips
proportional
For PuTDetail evaluations this indicator only differs from the Num ServiceTrips, if
there are trips with several trip sections and these differ in terms of the vehicle
combination. Different from the Number of Service Trips the number of service trips is
then distributed to trip sections. If the trip sections only differ with regard to the valid
days, the 'Num ServiceTrips proportional' value complies with 'Num ServiceTrips'.
Therefore, the evaluation of this indicator is useful for territory analyses only for levels
in combination with xVehComb.
Num
ServiceTrips
TSys
Different from the Num.ServiceTrips, the number of service trips is returned by
transport system. Calculation is otherwise analog.
MeanServiceLen
gth
Calculation is dependent on the network object.
For a transport system applies
Otherwise it applies
Service kilometers
Number Service trips
---------------------------------------------------------
Service kilometers
Number Departures
----------------------------------------------------
576 PTV AG
Calculation example: Number of departures per transport system
Number of departures for analysis period = number of service trips, which depart on Jan 02,
2006
For the bus, the number of departures (AP) = 76 (Trips no. 96 to 172)
For the train, the number of departures (AP) = 38 (Trips no. 58 to 95)
Number of departures for analysis horizon = Num Departures (AP) projection factor of
valid day
For the bus, the number of departures is calculated (AH) = 38 365 + 38 260 = 23750
For the train, the number of departures is calculated (AH) = 38 365 = 13870
Number of departures for analysis time period TI1 = Number of service trips, whose
departure time lies between 8 a.m. and 9 a.m.
For the bus, the number of departures results from (TI1) = 7 (Trip no. 99, 100, 119, 120,
138, 139, 157)
For the train, the number of departures results from (TI1) = 3 (Trip no. 61, 80, 81)
Calculation example: Number of service trips per transport system
For the analysis period and the analysis horizon, the number of service trips complies with the
number of departures in this example. The difference between the two indicators can be seen
when looking at the analysis time interval TI1. Now also service trips are counted, whose
departure does not lie in the time interval between 8:00 a.m. and 9:00 a.m., though they are
running in this time slice.
Number of service trips for analysis time interval TI1 = Number of service trips, whose
departure time lies between 8 a.m. and 9 a.m.
For the bus, the resulting number of service trips (TI) = 10 (Trip no. 98, 99, 100, 118, 119,
120, 138, 139, 156, 157)
For the train, the resulting number of service trips (TI) = 4 (Trip no. 60, 61, 80, 81)
7.6.3 Measurement of the transport supply
Transport supply indicators express operational efforts in length units or in time units. Demand
data is not required for their calculation.
MeanServiceTim
e
Calculation is dependent on the network object.
For a transport system applies
Otherwise it applies
isCoupled (Respective) time profile is coupled with another time profile (1) or not coupled (0).
IsEffectivelyCou
pled
Coupling is effective, if a trip which is coupled to another trip via a respective time
profile, actually runs (this means, that for each coupled TP at least one trip has to exist
which is active and furthermore has a valid ValidDay. A valid ValidDay lies within the
analysis period and both coupled trips run on the same day).
Service time
Number Service trips
--------------------------------------------------------
Service time
Number Departures
----------------------------------------------------
577 PTV AG
Service Kilometers Kilometers covered on service trips. Trip length via all service trips and number of
departures.
Section Service
Kilometers
Compared to ServiceKm, the length of each individual vehicle journey section is
added (as long as it lies within the analysis period).
ServiceTime Time required by service trips. Duration via all service trips and number of
departures.
Section Service
Time
Compared to service time, the duration of each individual vehicle journey section is
Empty Kilometers Kilometers covered on empty trips. Compared to service trips, no passengers are
carried on empty trips.
Empty kilometers = Pull-out kilometers + Interlining kilometers + Pull-in kilometers
Section Empty
Kilometers
Compared to EmptyKm, the length of each individual vehicle journey section is
EmptyTime Time covered on interlining trips Compared to service trips, no passengers are
carried on empty trips.
EmptyTime = Pull-out time + Interlining time + Pull-in time
Section Empty
Time
Compared to empty time, the duration of each vehicle journey section is added (as
long as it lies within the analysis period).
Operating
kilometers
Operating kilometers = Service kilometers + Empty kilometers
Section operating
kilometers
Compared to OperatingKm, the length of each individual vehicle journey section is
Operating Time Operating time = Service time + EmptyTime
Section Operating
Time
Compared to operating time, the duration of each vehicle journey section is added
(as long as it lies within the analysis period).
SeatCap Sums up the number of seats of the vehicle combinations over all vehicle journey
sections of the object, for which the indicator is determined (e.g. lines). This attribute
is only available for the elements of the line hierarchy and for PuT operators and
transport systems.
Seat Kilometers Seat Km = Section Service Km Number of seats of vehicle combinations
Summed up over all vehicle journey sections and number of departures.
Seat Hours Seat Hours = Section Service Time Number of seats of vehicle combinations
Summed up over all vehicle journey sections.
Total Capacity Sums up the total seating and standing capacity of the vehicle combinations over all
vehicle journey sections of the object, for which the indicator is determined (for
example, lines). This attribute is only available for the elements of the line hierarchy
and for PuT operators and transport systems.
Total Capacity
Kilometers
Total Capacity Km = Section Service Km Total seating and standing capacity of the vehicle
combinations
Summed up over all service trip sections.
Total Capacity
Hours
Total Capacity Hours = Section Service Time Total seating and standing capacity of the
vehicle combinations
Summed up over all vehicle journey sections.
Table 215: Indicators of the transport supply
578 PTV AG
Calculation example: Service kilometers per transport system
Service km for the analysis period = Number of trips (AP) Trip length.
For the bus it applies that ServiceKm (AP) = 38 27.5 km + 38 7.5km = 1,045 km +
285 km = 1,330 km
For the train it applies that ServiceKm (AP) = 38 10 km = 380 km
Service km for the analysis horizon = Service km (AP) Projection factor of the valid day
For the bus it applies that ServiceKm (AH) = 1045 km 365 + 285 km 260 = 455525 km
For the train it applies that ServiceKm (AH) = 380 km 365 = 138700 km
Service km for the analysis time interval TI1 results from summing up the km data from all
trip sections, whose respective line route items depart in this time slice
For the bus it applies that ServiceKm (TI1) = 113.75 km. The calculation is made clearer by
illustration 188.
Length Length covered by the time profile items in the territory. (Attribute is available via
Territory - PuT Detail only for level Territory x Time profile (x Vehicle Combination).)
Run time Time used for covering the time profile items in the territory. (Attribute is available via
Territory - PuT Detail only for the level Territory x Time profile (x Vehicle
Combination).)
Mean Speed Mean speed = Service kilometers / Service time
Capacity PuT
Seats
Number of seats of vehicle combinations, which traverse this link, summed up over
all vehicle journey sections. (Attribute is only available for links.)
Capacity PuT total Total seating and standing capacity of the vehicle combinations, which traverse this
link, summed up over all vehicle journey sections and the number of departures
(Attribute is only available for links).
Number of
Vehicles (in
proportion to
length)
The number of vehicles which are - according to the current block version - required
for the reference object, (line, line route, etc.). The indicator value corresponds to the
number of blocks, which cover the vehicle journey sections of the reference object.
If a block covers vehicle journey sections of several objects, for the vehicle only the
proportion of the vehicle journey sections of the reference object is added to the line
length of all vehicle journey sections.
Number of
vehicles (in
proportion to time)
As above, but the addition to the reference object is instead carried out with the
share of vehicle journey sections of the reference object in the service time of all
vehicle journey sections.
Table 215: Indicators of the transport supply
579 PTV AG
Illustration 188: Calculation of service kilometers between 8 a.m. and 9 a.m.
For the train it applies that ServiceKm (TI1) = 3 10 km = 30 km (Trip numbers 61, 80, 81)
Calculation example: Seat km per transport system
Seat km for the analysis period = ServiceKm (AP) Number of seats summed up over all
trip sections.
For the bus it applies that SeatKm (AP) = 1330 km 35 = 46550 km
For the train it applies that SeatKm (AP) = 380 km 200 = 76000 km
Seat km for the analysis horizon = Seat km (AP) Projection factor of the valid day summed
up over all trip sections.
For the bus it applies that SeatKm (AH) = 38 262.5 km 260 + 38 962.5 km 365 =
15,943.375 km
For the train it applies that SeatKm (AH) = 76000 km 365 = 27740000 km
For seat km in the analysis time interval TI, the calculation is analog to the service km
calculation (illustration 188).
For the bus it applies that SeatKm (TI) = 35 (27.5 + 3.75 + 15 + 12.5 + 5 + 27.5) km + 35
(7.5 + 7.5 + 7.5) = 3,981.25 km
For the train it applies that SeatKm (TI) = 30 km 200 = 6000 km
580 PTV AG
Calculation example: Service time per transport system
Service time for the analysis period = Num PuT Departures (AP) Times from Time profiles
For the bus it applies that ServiceTime (AP) = 38 45 min + 38 13 min = 2204 min = 36 h
44 min
For the train it applies that ServiceTime (AP) = 38 16 min = 608 min = 10h 8 min
Service time for the analysis horizon = Service time (AP) Projection factor of the valid day
summed up over all trip sections.
For the bus it applies that Service time (AH) = 38 45 min 365 + 38 13 min 260 =
752590 min = 12543 h 10 min
For the train it applies that Service time (AH) = 38 16 min 365 = 221920 min = 3698h
40 min
Service time for the analysis time interval TI: Calculation is done analog to the service
kilometer calculation (illustration 188).
For the bus it applies that service time (TI) = 45 min + 13 min + (5 km/10 km) 13 min +
12 min + (5 km/10 km) 20 min + 13 min + 13 min + (5 km/10 km) 20 min + 0 min + (5 km/
10 km) 12 min + 45 min + 13 min = 186.5 min = 3 h 10 min
For the train it applies that Service time (TI) = 3 16 min = 48 min
Calculation example: Mean speed per PuT line
Mean speed = ServiceKm(AP) / ServiceTime (AP)
For the bus it applies that vMean = 1330 km / 36h 44 min = 36.2 km/h
For the train it applies that vMean = 380 km / 10 h 8 min = 37.5 km/h
7.6.4 Measurement of the network performance
The indicators of the network performance result from the PuT line use by passengers. For the
calculation of the indicators, the volumes have to be available from the PuT assignment. Some
of the indicators are automatically calculated during assignment (see overview table
IndicatorSource.xls in the directory ...\VISUM115\Doc\Eng).
]
Passenger
kilometers
(DSeg)
The link that passengers are driving with the PuT vehicle
Passenger kilometers = Passenger trips unlinked trip distance from Boarding to Alighting
stop
Passenger hours
(DSeg)
Time which the passengers spend in the PuT vehicle
Passenger hours = Volume Duration
Passenger trips
TSys (DSeg)
Repeated boarding the same transport system is not counted more than once (for
example transferring from one bus into another).
Passenger trips
Unlinked /
Passenger trips
Unlinked PuT
Unlinked passenger trips match the number of boarding passengers per object.
Counts each passenger using at least one line route item in the territory. No
passengers are counted for path legs that end exactly at the start or start exactly
at the end of a time interval.
PTrips Unlinked
PuT DSeg
Number of passengers boarding per object additionally differentiated according to
demand segments. This attribute is only available for zones.
Table 216: Indicators of the network performance
581 PTV AG
PTrips Unlinked
>2xTransfer
(DSeg)
Passenger trips with 3 or more transfers on their way from origin zone to
destination zone. This attribute is only available for the elements of the line
hierarchy.
PTrips Unlinked
with 0xTransfer
(DSeg)
Passenger trips without transfer on their way from origin zone to destination zone.
This attribute is only available for the elements of the line hierarchy.
PTrips Unlinked
with 1xTransfer
(DSeg)
Passenger trips with exactly one transfer on their way from origin zone to
hierarchy.
PTrips Unlinked
with 2xTrans
(DSeg)
Passenger trips with exactly two transfers on their way from origin zone to
hierarchy.
PTrips Unlinked
DSeg
Number of boarding passengers per object additionally differentiated according to
demand segments. This attribute is only available for the elements of the line
hierarchy.
Mean volume per
trip
Mean volume per trip = passenger kilometers / service kilometers
Mean volume to
seat capacity ratio
Mean volume to seat capacity ratio = passenger kilometers / seat kilometers 100
(This attribute is only available for the elements of the line hierarchy.)
Volume seat
capacity ratio
Volume seat capacity ratio = volume / seat capacity 100
(always starting from the journey item. This attribute is only available for the
elements of the line hierarchy.)
Mean vol/cap ratio
total
Mean volume total capacity ratio = passenger kilometers / total capacity kilometers 100
(This attribute is only available for the elements of the line hierarchy.)
Total vol/cap ratio Total volume capacity ratio = volume / total capacity 100
(always starting from the journey item. This attribute is only available for the
elements of the line hierarchy.)
Total vol/cap ratio
PuT
Volume capacity ratio PuT total = volume / total capacity 100
This attribute is only available for the elements of the line hierarchy.
Boarding
passengers (DSeg)
Number of boarding passengers. This also includes passengers, which are
transferring from another line (This attribute is only available for the elements of the
line hierarchy and for stops and stop points.).
Alighting
passengers (DSeg)
Number of alighting passengers. This also includes passengers, which are
transferring to another line (This attribute is only available for the elements of the
line hierarchy and for stops and stop points.).
PassOrigin
(DSeg)
Number of boarding passengers, which have this stop as their origin. Passengers
which transfer here are therefore not counted. (This attribute is only available at
stops and stop points.)
PassDestination
(DSeg)
Number of alighting passengers, which have this stop as their destination.
Passengers which transfer here are therefore not counted. (This attribute is only
available at stops and stop points.)
582 PTV AG
Calculation example: Passenger trips per line
Number of Passenger trips per analysis period
For the bus it applies that 8400 = 200(A->C) + 200(C->A) + 2000(A->X) + 2000(X->A) +
2000(B->X) + 2000(X->B)
For the train it applies that 12000 = 5000(C->X) + 5000(X->C) + 1000(A->X) + 1000(X->A)
Passenger trips 0 transfers analysis period
For the bus it applies that 6400 = 400(A<->C) + 2000(A<->X direct) + 4000(B<->X)
For the train it applies that 10000 = 5000(C<->X) + 5000(X->C)
Passenger trips 1 transfer analysis period
For the bus it applies that 2000 = 2000(A<->X with transfer between bus and train)
For the bus it applies that 2000 = 2000(A<->X with transfer between bus and train)
Calculation example: Passenger kilometers per line
The value Passenger kilometers per analysis period is calculated as follows: PassKm(AP)
= Passenger trips trip distance from Boarding to Alighting stop
For the bus it applies that 2400 10 km(A<->C) + 2000 27.5 km(A<->X) + 4000
7.5 km(B<->X) = 109000
For the train it applies that 12000 10 km(C<->X) = 120000
PassThrough Number of through-going passengers. These are all passengers traveling with a
line, which traverses this item of a line route / time profile / service trip, however,
they neither board nor alight here (This attribute is only available for the elements
of the line hierarchy).
PassThrough with
stop (DSeg)
Number of passengers with stop event. These are all passengers traveling with a
line which stops at this stop point, however, they neither board or alight here (This
attribute is only available for stops and stop points).
PassThrough
without stop (DSeg)
Number of through passengers without stop event. These are all passengers
traveling with a line, which passes the stop point, but does not stop there.
(This attribute is only available for stops and stop points.)
PassTransfer Number of passenger transfers in the territory
(This attribute is only available for territories).
PassTransTotal
(DSeg)
Total number of passengers transferring at this stop or stop point
PassTransAlightWa
lk (DSeg)
Number of passengers alighting at this stop or stop point and walking to another
stop or stop point for transfer
PassTransDir
(DSeg)
Number of passengers transferring to another line at this stop or stop point.
PassTransWalkBoa
rd (DSeg)
Number of passengers boarding at this stop or stop point after walking from
another stop or stop point.
583 PTV AG
The value Passenger kilometers per analysis horizon is calculated as follows: PassKm(AH)
= PassKm(AP) Projection factor of the demand segment summed up over all demand
segments.
For the bus it applies that 109000 km 365 = 39785000 km
For the train it applies that 120000 km 365 = 43800000 km
Passenger kilometers per analysis time interval TI:
For the bus it applies that 9660 km. The calculation can be taken from illustration 189:
Illustration 189: Calculation of passenger kilometers between 8:00 a.m. and 9:00 a.m.
For the train it applies that 3 10 km 316 = 9480 km
Calculation example: Passenger hours per transport system
The value Passenger hours per analysis period is calculated as follows: PassHour(AP) =
Passenger trips Run time from Boarding to Alighting stop.
For the bus it applies that 2400 12 min + 2000 45 min + 4000 13 min = 2846 h 40 min
For the train it applies that 12000h 16 min = 3200 h
Note: Unlike the calculation of transport supply indicators, the projection factor of the demand
segment is regarded for the network performance indicators' projection to the analysis
horizon (AH) (see User Manual, Chpt. 2.10.3, page 179).
584 PTV AG
The value Passenger hours per analysis horizon is calculated as follows: PassHour(AH) =
PassHour(AP) Projection factor of the demand segment summed up over all demand
segments.
For the bus it applies that 2846 h 40 min 365 = 1039033 h 20 min
For the train it applies that 3200 h 365 = 1168000 h
The value Passenger hours per analysis time period TI is calculated as follows.
For the bus it applies that 255 h 55 min. The calculation can be taken from illustration 190.
Illustration 190: Calculation of passenger kilometers between 8 a.m. and 9 a.m.
For the train it applies that 3 16 min 316 = 252 h 48 min
7.6.5 Calculation of operating costs and fare gains (revenues)
illustration 191 gives an overview of the cost and revenue model in VISUM and the interrelation
with the assignment results. The attribute names are bold in the depiction. Different settings
have to be made (see User Manual, Chpt. 7.3.2, page 1076).
585 PTV AG
Illustration 191: Calculation schema for costs and revenues
7.6.6 Calculation of the operating costs
The total costs can be divided into vehicle-dependent costs and infrastructure costs. These are
the provided cost blocks:
Note: Please note that the reference period for costs and the reference period for revenues
have to match, in order to get reasonable cost coverage results. The revenues are calculated
for the assignment time interval. The attribute passenger trips total reflect the number of
passenger trips in the assignment time interval, which means that there is a variation in the
dependency of the length of the assignment time interval. The revenues therefore also vary
in dependency of the choice of assignment time interval. The costs however, are based on
the analysis period. Because the assignment time interval often only comprises the peak hour
(for example the evening rush hour from 4 p.m. to 6 p.m.), it is necessary to project this result
to the analysis period, when calculating cost coverage in your model or if you want to
combine indicators, which are calculated in the assignment, with indicators which are
calculated in the procedure PuT operating indicators (file IndicatorSource.xls in the directory
...\VISUM115\Doc\Eng). To create the same reference period, you have to define a projection
factor from the assignment time interval to the analysis period on the demand segment (see
User Manual, Chpt. 7.2, page 1072). The projection factor 1 is only correct here, if you carry
out an assignment for the whole day.
586 PTV AG
The total costs which accumulate for operating public transport, are returned in the following
attribute.
7.6.6.1 Vehicle type-dependent costs
The costs for a vehicle is composed of hourly costs, kilometer costs and fixed costs. In VISUM,
these costs are assigned to vehicle units (see User Manual, Chpt. 7.2.2, page 1072). In
practice these kilometer and vehicle costs are dependent on the vehicle type used (for
example standard or articulated bus, or tram in single or multiple traction) and the hourly costs
of the operator (for example public or private operator, type of labor contract).
Vehicle type-dependent costs
Hourly costs / Cost
time
Time-dependent costs for personnel
Time costs = service time hourly costs rate of service trips + empty time hourly cost
rate of empty trips
Kilometer costs /
Cost distance
Kilometer-dependent costs for fuel, repairs, etc.
Distance costs = ServiceKm kilometer cost rate of service trips + empty kilometer
kilometer cost rate of empty trips
Vehicle costs / Cost
vehicle
Assigned fixed cost for a vehicle (debt service as well as other fixed costs such as
insurance costs).
Vehicle costs = cost rate per vehicle unit number of vehicles
The number of vehicles is an output attribute of line blocking.
Table 217: Vehicle type-dependent costs
Infrastructure costs
Stop point costs /
Cost stop point
Costs for the usage of stop points These can be composed of depreciation costs
(for example investment costs), running costs (for example maintenance costs)
and utilization costs (for example fees for using the stops).
Costs 1/2/3 stop
points
Three cost rates which are included in the calculation of stop point costs (see
"Stop point costs" on page 590).
Link costs / Cost
links
Costs for the usage of links (infrastructure cost) The link costs are divided equally
between the service trips which use the link.
Costs 1/2/3 links Three cost rates which are included in the calculation of link costs (see "Link
costs" on page 588).
Operator costs /
Costs operator
Share of costs for general operational costs These can be composed of
depreciation costs (for example investment costs) or running costs (for example
maintenance costs).
Costs 1/2/3
operators
Three cost rates which are included in the calculation of operator costs (see
"Operator costs" on page 591).
Table 218: Infrastructure costs
Total costs
Costs Costs = time costs + distance costs + vehicle costs + stop point costs + link costs + operator
costs
Table 219: Total costs
587 PTV AG
Hourly costs (attribute Cost time)
Time costs = service time hourly costs rate of service trips + empty time hourly cost rate of empty
trips
Service time describes the time for passenger transport. It can be taken from the
timetable.
Empty time comprises the times for delay buffers, driver breaks or interlining and
layover. Line blocking is required for determining the empty times, otherwise this share
is not included in the hourly costs.
Kilometer costs (attribute Cost distance)
Distance costs = ServiceKm kilometer cost rate of service trips + empty kilometers kilometer cost
rate of empty trips
Service kilometers for transporting passengers are calculated directly from the service
trips in the timetable.
Empty kilometers arise from interlining trips between the last stop of a service trip and
the first stop of another service trip, within a block.
Vehicle costs (attribute Cost vehicle)
Vehicle costs result from the fixed costs, which can be defined for each vehicle unit (see User
Manual, Chpt. 2.27.2, page 371), and the vehicle demand determined by PuT line blocking.
Vehicle costs = cost rate per vehicle unit number of vehicles
The attribute Cost rate per vehicle unit contains the fixed costs for each vehicle unit (the
acquisition costs for example). Fixed costs increase with every additional vehicle
required.
The value Number of vehicles results from the necessary vehicle blocks. Line blocking
is therefore assumed for the calculation of vehicle costs.
Calculation example: Vehicle type-dependent costs for lines
The following vehicle type-specific cost rates are the basis for the example (see
"Demonstration example" on page 569).
Vehicle units Standard bus Low floor bus Train
Cost rate per km [CU/km] 5.00 5.00 5.00 5.00 10,00 10,00
Cost rate per vehicle unit [CU/
Veh]
7000.00 7000.00 20000.00
Reference period of the cost
rate per vehicle unit
Analysis period Analysis period Analysis period
Table 220: Cost rates for the vehicle units
Vehicle combinations Standard bus Low floor bus Train
Table 221: Cost rates for the vehicle combinations
588 PTV AG
The following distances and times accumulate for the train:
Calculating the vehicle type-dependent costs (distance costs, time costs and vehicle costs) for
lines returns the following result for the Train line.
Distance costs / analysis period
CostDist(AP) = CostKmService ServiceKm(AP) + CostKmEmpty EmptyKm(AP)
Time costs / analysis period
CostTime(AP) = CostTimeService ServiceTime(AP) + CostTimeEmpty EmptyTime(AP)
Vehicle costs / analysis period
CostVehicle(AP) = Cost rate vehicle unit Number of vehicles
7.6.6.2 Link costs
Link costs are infrastructure costs, which accumulate when using a link. The link costs are
divided equally between the service trips which use the link. Up to three cost values (attribute
CostRate1 to 3) can be specified per link and transport system to model link costs (see User
Manual, Chpt. 2.13.7, page 219). For each of these three cost values, one of the following cost
types can be selected:
Depreciation costs, for example annual costs for depreciation and interest rates which
result from the investment cost for the link
Running costs, for example maintenance costs and operating costs
Utilization costs, for example fees for using stop points or tracks
Dependent on the selected cost type, the allocation of the costs to the individual service trips
is then carried out according to the formulas described below.
Cost rate per km [CU/km] 0.00 0.00 0.00 0.00 0.00 0.00
Vehicle combination ServiceKm EmptyKm ServiceTime EmptyTime
Train 380 km 0 km 10.13 h 0 h
Table 222: Distances and times for the vehicle combination Train in the analysis period
Vehicle combinations Standard bus Low floor bus Train
Table 221: Cost rates for the vehicle combinations
10
CU
km
-------- = 380km 10
CU
km
-------- + 0km 3800CU =
750
CU
h
-------- = 10 13h , 500
CU
h
-------- + 0h 7600CU =
20000
CU
Veh
---------- = 1Veh 20000CU =
589 PTV AG
Calculation example: Link costs for service trips in the analysis period
Example for depreciation costs
Cost type depreciation costs
CostValue: for example investment costs for a link (link attributes CostRate1-3 PuTSys)
Cost type running costs
CostValue: for example annual maintenance costs for a link (link attributes CostRate1-3 PuTSys)
Cost type utilization costs
CostValue: for example fees for using a link (link attributes CostRate1-3 PuTSys)
CostsLink
Service trip, L, T
= CostValue
L, T
CostValue
L, T
Cost value which is entered as attribute of the link. For running costs
the value can refer to AP or AH. Depreciation costs and utilization
costs can either be distributed to all service trips or allocated only to
service trips which end or start at this stop point (see User Manual,
Chpt. 7.3.2.5, page 1081).
CostsLink
AP, L, T
Link costs of the link in the analysis period (AP)
CostsLink
Service trip, L, T
Costs for a service trip which uses the link
V
L, T
Number of service trips of transport system T which use link L.
FacTS The transport supply projection factor from AP to AH (see User
Manual, Chpt. 2.41.3, page 553)
DT Depreciation time in years
p Interest rate [%]
Table 223: Formulas for calculating link costs
Cost rate 2 PuTSys(Train) 100000 CU
Interest rate p 7 %
Depreciation time DT 10 years
Projection factor transport supply (FacTS) 365
Number of service trips of the transport system
train
19
Table 224: Example calculation for link depreciation costs
KostenStr
AP S V , ,
KostenWert
S V ,
q
AD
q 1
q
AD
1
----------------------------------------------------------------------

1
FakVA
------------------ = mit q 1
p
100
--------- + =
( )
100 1
1
1
1
,
, ,
p q with
FacTS
DT
q
q
DT
q
T L
CostValue
T L AP
CostLink + =
=
T L T L AP T L VehJourn
VehJourn CostLink CostLink
, , , , ,

=
FacTS
T L
VehJourn
T L
CostValue
T L VehJourn
CostLink
,
,
, ,
590 PTV AG
Example for running costs
Example for utilization costs (in the example, stored in attribute Link Cost 1)
7.6.6.3 Stop point costs
Stop point costs are infrastructure costs which accumulate when using a stop point. The stop
point costs are defined for each stop point. The costs are evently distributed between the
service trips which allow boarding and alighting on this stop point. To model the costs, up to
three cost values (attributes Cost rate1 to Cost rate3) may be entered for each stop point (see
User Manual, Chpt. 2.25.2, page 357). For each of these three cost values, one of the following
cost types can be selected.
Depreciation costs, for example annual costs for depreciation and interest rates which
result from the investment cost for the link
Running costs, for example maintenance costs and operating costs
Utilization costs, for example fees for using stop points or tracks
Dependent on the selected cost type, the allocation of the costs to the individual service trips
is then carried out according to the formulas described below.
Link Cost 2 of link 4
CostsLink
AP, L, T
Link Cost 2 of service trip 58 39,008 / 19 = 2,053
Cost rate 3 PuTSys(Bus) 100 CU
Links traversed by service trip 96 1 -> 2 -> 3 -> 5 -> 6 -> 7
Link lengths 5 km per link
Length reference of cost rate 3 Link length
Time reference of cost rate 3 Analysis horizon
Link Cost 2 for share of links 1, 2, 3 and 5 4 (20 CU / (19 365)) = 0.01154 CU
Link Cost 2 for share of links 6 and 7 2 (20 CU / (38 365)) = 0.00288 CU
Link Cost 2 for service trip 96 0.01154 + 0.00288 = 0.01442 CU
Table 225: Example calculation for running costs of links
Cost rate 1 PuTSys(Train) 100 CU
Length of link 4 10 km
Length reference of cost rate 1 km
Link Cost 1 for service trip (in this example, it is
constant for all trips of the train)
100 CU/km 10km = 1000 CU
Table 226: Example calculation for link utilization costs
Table 224: Example calculation for link depreciation costs
100000 1.07
10
0.07
1
1.07
10
1
-------------------------
1
365
--------- 39.008 =
591 PTV AG
7.6.6.4 Operator costs
Up to three cost values (attributes Cost rate1 to 3) can be entered for each operator. For each
of these three cost values, one of the following cost types can be selected.
Depreciation costs, for example investment costs (debt service for depot and offices)
Running costs, for example maintenance costs (maintenance for the depot and
administrative/sales costs).
To distribute operator costs to the service trips, which are operated by this operator, a
distribution key can be specified which consists of the following weighted indicators
Service kilometers (GewServKm)
Seat kilometers (WeightSeatKm)
Service time (WeightServiceTime)
Number of service trips (GewServFahrt)
CostValue: for example investment costs for a stop point (Stop point attributes CostRate1 to 3)
CostValue: for example annual maintenance costs for a stop point (Stop point attributes CostRate1 to 3)
Cost type utilization costs
CostValue: for example fees for using a stop point (Stop point attributes CostRate1 to 3)
CostSP
Service trip, SP
= CostValue
SP
CostValue
SP
Cost value which is entered as an attribute of the stop point SP. For running
costs the value can refer to AP or AH. Depreciation costs and utilization costs
can either be distributed to all service trips or allocated only to service trips
which end or start at this stop point.
CostsSP
AP, HP
Stop point costs of the stop point SP in the analysis period (AP).
CostsSP
V, HP
Costs for a service trip which uses the stop point SP.
Service trip
SP
Number of service trips which use stop point SP.
FacTS The transport supply projection factor from AP to AH (see User Manual, Chpt.
2.41, page 550)
p Interest rate [%]
Table 227: Formulas for the calculation of stop point costs
KostenHP
AP HP ,
KostenWert
HP
q
AD
q 1 ( )
q
AD
1
--------------------------------------------------------------------------
1
FakVA
------------------ =
( )
100 1
1
1
1
,
, ,
p q with
FacTS
DT
q
q
DT
q
T SP
CostValue
T SP AP
CostStopP + =
=
T SP
VehJourn
T SP AP
CostStopP
T SP VehJourn
CostStopP
, , , , ,

=
FacTS
T SP
VehJourn
T SP
CostValue
T SP VehJourn
CostSP
,
,
, ,
592 PTV AG
Passenger trips unlinked (WeightPTripsUnlinked)
Passenger kilometers (WeightPassKm).
With the values of any combination of these six attributes, you can thus distribute the operator
costs onto service trips. The weighting factors must amount to 100 % (see User Manual, Chpt.
7.3.2.5, page 1081).
Distribution of operator costs O on a service trip
The share of one service trip in operator (O) costs:

CostValue
B
: for example investment costs for a depot
CostValue
B
: = for example annual maintenance costs for the depot
Share
V
The share of one service trip in operator (O) costs
F
O
Number of all service trips of operator O
CostValue
O
Cost value which is specified as operator attribute
CostOp
AP, B
Operator costs of operator O in analysis period (AP)
CostOp
ServiceTrip
Operator costs for one service trip by operator O.
Table 228: Formulas for calculating operator costs
SeatKm W
L
i
i
SeatKm
VehJourn
SeatKm
SerKm W
L
i
i
SerKm
VehJourn
SerKm
VehJourn
Share
=
+
=
=

1 1
VehJourn W
V
ServiceT W
L
i
i
ServiceT
VehJourn
ServiceT
+
=
+
1
1
ps WeightPTri
PTrips
PTrips
Km WeightPass
PassKm
PassKm
neys NumVehJour
i
i
VehJourney
neys NumVehJour
i
i
VehJourney
+ +

= = 1 1
( )
100 1
1
1
1
,
p q with
FacTS
DT
q
q
DT
q
O
CostValue
O AP
CostOp + =

=
O VehJourn
Share
O AP
CostOp
O VehJourn
CostOp
, , ,
=
FacTS
O VehJourn
Share
O
CostValue
O VehJourn
CostOp
,
,

=
593 PTV AG
Calculation example: Depreciation costs
Calculation example: Running costs
FacTS The transport supply projection factor from AP to AH
p Interest rate [%]
Cost rate 1: Investment costs for depot 7500000 CU
Depreciation time DT 10 years
Interest rate 7%
Operator Cost 1 for "Urban operator"
= 2925.57 CU
Weight service kilometers 25 %
Service kilometers of trip 96 27.5 km
Service kilometers total for operator "Urban
operator"
1330km
Weight seat kilometers 25 %
Seat kilometers of trip 96 962.5 km
Seat kilometers total for operator "Urban
operator"
46550 km
Weight passenger kilometers 50 %
Passenger kilometers of trip 96 2495.0 km
Passenger kilometers total for operator
"Urban operator"
109000 km
Share of service trip 96 in operating costs
Operator Cost 1 for service trip 96 2925.57 CU 0.022 = 63.73 CU
Table 229: Calculation example for depreciation costs of the operator
Cost rate 2: Maintenance cost for depot 80000 CU
Time reference of the cost rate Analysis horizon
Operator Cost 2 for "Urban operator"
Weight service kilometers 25 %
Service kilometers of trip 96 27.5 km
Table 230: Calculation example for the running costs of the operator
Table 228: Formulas for calculating operator costs
7500000 1.07
10
0.07
1.07
10
1
-------------------------------------------------------
1
365
---------
27.5
1330
------------ 0.25
962.5
46550
--------------- 0.25
2495
109000
------------------ 0.5 = 0.022 + +
80000
365
---------------- 219.18 =
594 PTV AG
7.6.7 Calculation of the fare revenues (revenue calculation)
With VISUM revenues can be calculated and then distributed to the network objects. There are
three methods available for revenue calculation.
Specification of a fixed revenue for each passenger trip
For each passenger trip, a standard fare is assumed and distributed to the lines used by
the passenger. The revenue distribution can also be modified by specific parameter
settings (fixed amount per path leg, weighting per kilometer, weighting by number of path
legs).
Specification of a revenue for each fare point
The revenue results from the following calculation: revenue/fare point and the number of
fare points. The revenue distribution can also be modified by specific parameter settings
(fixed amount per path leg, weighting per kilometer, weighting by number of path legs).
Calculation of the revenues using the fare model
For each passenger trip, the fare is calculated from the current ticket type. This revenue is
then distributed over the lines used by the passenger. The revenue distribution can also be
modified by specific parameter settings (fixed amount per path leg, weighting per kilometer,
weighting by number of path legs and transport system-specific distribution of
supplements).
The decision for one of these three possibilities depends on the models desired level of detail,
the availability of input data and the planned work load for modeling the revenue calculation.
The three possibilities of revenue calculation in VISUM are described in the following. For each
possibility, an example calculation is carried out using the application example data.
Independent of the selected type of revenue calculation, the following output attributes
(revenue indicators) are available.
Service kilometers total for operator "Urban
operator"
1330 km
Weight seat kilometers 25 %
Seat kilometers of trip 96 962.5 km
Seat kilometers total for operator "Urban
operator"
46550 km
Weight passenger kilometers 50 %
Passenger kilometers of trip 96 2495.0 km
Passenger kilometers total for operator "Urban
operator"
109000 km
Share of service trip 96 in operating costs
Operator Cost 2 for service trip 96
Table 230: Calculation example for the running costs of the operator
27.5
1330
------------- 0 25 ,
962.5
46550
---------------- 0 25 ,
2495.0
109000
-------------------- 0.50 + + 0.022 =
80000 0.022
365
------------------------------------- 4.5 CU =
595 PTV AG
7.6.7.1 Revenue calculation from fixed revenue per passenger trip
To estimate the revenues from ticket fares, a revenue amount per passenger trip can be
specified. In the following example, a fixed revenue of 4.00 CU per passenger trip is specified
and the revenue per line calculated. The distribution regards only the number of path legs (see
"Revenue distribution" on page 598). The following route table (PuT path legs) provides an
overview of all other indicators required, including the passenger trips.
Total revenue Total revenue from fare revenues which apply to the network object.
Total revenue
(length proportional)
Total revenue from fare revenues which apply to the territory and the selected
level. Distribution is proportional to the link lengths of the traversed links.
Total revenue
(fare point-
proportional)
Total revenue from fare gains which apply to the territory and the selected level.
Distribution is proportional to the number of traversed fare points on links and time
profiles.
Revenue
PTripUnlinked
Revenue per passenger trip = Revenue total / PTripsUnlinked
Cost coverage % Expresses the cost coverage in percent
Cost coverage % = Revenue total (length proportional) / Costs 100
CostCov total Expresses the cost coverage in absolute numbers
Cost coverage total = Revenue total (length proportional) - Costs
Cost coverage
per PTripUnlinked
Cost coverage per passenger trip = Cost coverage total / passenger trips
Table 231: Revenue indicators
From zone To zone Line FromS
Point
ToSPoi
nt
Passenge
r trips
Fixed revenue
per passenger
trip [CU]
Revenue
share
(Weighted
with number
of path legs)
A Village
(100)
X City (200) BUS1 10 20 1501 4.00
Train 20 40 4.00
A Village
(100)
X City (200) BUS1 10 40 499 4.00 499 4.00
A Village
(100)
C Village
(201)
BUS1 10 20 200 4.00 200 4.00
X City (200) A Village
(100)
BUS1 40 10 1000 4.00 1000 4.00
X City (200) A Village
(100)
Train 40 20 1000 4.00
Table 232: Revenue share per path leg
1501 4
2
---------------------
1501 4
2
---------------------
1000 4
2
---------------------
596 PTV AG
Revenues per line then result from summation of the revenue shares for each line.
7.6.7.2 Revenue calculation from fixed revenue per traversed fare
point
If fare points have been defined on links or in time profiles of the model, revenue calculation
can regard a fixed revenue per traversed fare point (see User Manual, Chpt. 7.5, page 1086).
In the following example, a revenue of 0.20 CU per fare point is specified. The route table (PuT
path legs) provides an overview of the calculation.
BUS1 20 10 4.00
X City (200) C Village
(201)
Train 40 20 5000 4.00 5000 4.00
X City (200) B Village
(202)
BUS1 40 30 2000 4.00 2000 4.00
C Village
(201)
A Village
(100)
BUS1 20 10 200 4.00 200 4.00
C Village
(201)
X City (200) Train 20 40 5000 4.00 5000 4.00
B Village
(202)
X City (200) BUS1 30 40 2000 4.00 2000 4.00
Line Revenue per line
Bus1 3002 + 1996 + 800 + 4000 + 2000 + 8000 + 800 + 8000 = 28598
Train 3002 + 2000 + 20000 + 20000 = 43996
Table 233: Revenue per line
From
Zone
To
Zone
Line From
SPoint
To
SPoint
NumF
P
PTrips Fixed
revenue per
FP [CU]
Revenue share (Weighted
with number of path legs)
100 200 BUS1 10 20 10 1501 0.20
Train 20 40 20 0.20
100 200 BUS1 10 40 29 499 0.20
100 201 BUS1 10 20 10 200 0.20
200 100 BUS1 40 10 30 1000 0.20
200 100 Train 40 20 20 1000 0.20
1000 4
2
---------------------
1501 10 20) 0.2 + ( )
2
------------------------------------------------------------
1501 10 20) 0.2 + ( )
2
------------------------------------------------------------
499 29 0.2
200 10 0.2
1000 30 0.2
1000 20 10 + ( ) 0.2
2
--------------------------------------------------------
597 PTV AG
Revenues per line then result from summation of the revenue shares for each PuT path leg.
Fare points can be created for links and also for time profiles. In the calculation of the revenue
share for each path leg, the sum of fare points at both of those network objects goes in.
Illustration 192: Calculation of the fare points for path legs
7.6.7.3 Revenue calculation using the fare model
The most exact variant of the revenue calculation is the one which builds up on the VISUM fare
model. To do so, fare systems and ticket types have to be defined and connected with the
network lines (see "PuT fare model" on page 546). A fare model provides a specific fare for
each PuT path.
BUS1 20 10 10 0.20
200 201 Train 40 20 20 5000 0.20
200 202 BUS1 40 30 10 2000 0.20
201 100 BUS1 20 10 10 200 0.20
201 200 Train 20 40 20 5000 0.20
202 200 BUS1 30 40 10 2000 0.20
Line Revenue per line
Bus1 4503 + 2894 + 400 + 6000 + 3000 + 4000 + 400 + 4000 = 25197
Train 4503 + 3000 + 20000 + 20000 = 47503
Table 235: Revenue per line
1000 20 10 + ( ) 0.2
2
--------------------------------------------------------
5000 20 0.2
2000 10 0.2
200 10 0.2
5000 20 0.2
2000 10 0.2
H1 H2 H3 H4 H5
2 5 6 3
10 10 10
TW1 TW2 TW3
Path legs
TP at l inks (NumTPs-TSys)
TP at time profil es (NumTPs)
Stop points
TP at pat h legs (NumTPs) 12 21 13
598 PTV AG
The revenue is first calculated on PuT path level. The passenger trips (volume) of the path are
thus multiplied with the fare. The revenue is then distributed to the PuT path legs (see
"Revenue distribution" on page 598). With a zone-based fare, the following revenues result for
the paths in the example Example_LLE.ver .
7.6.7.4 Revenue distribution
Internally VISUM first calculates the revenues for PuT paths. The revenues are then distributed
to the PuT path leg and then converted to the network object line hierarchy (lines, line routes,
etc.). You can influence the distribution of the revenues by the following parameters.
With Weighting Number Path Legs you can achieve an even distribution of the revenue
over all path legs. Each path leg receives the same revenue share, if the weight is 100%.
With Weighting Number Fare Points, the distribution takes the ratio between the number
of fare points of the path leg and the number of fare points of the entire path into
consideration. This can be used so that the longer path legs (in terms of fare points) thus
receive a larger share of the revenue.
You can select any weighting between both distribution possibilities, number of path legs
and number of fare points.
When specifying Fixed amount per path leg, each path leg first receives a fixed sum of
the total revenue. The remaining revenue is then distributed to the path legs according to
the distribution rules mentioned above. If the sum of all of the fixed amounts exceeds the
revenue to be distributed, the fixed amounts are correspondingly reduced. If a fare model
is used, the supplements are not taken into consideration.
F
r
o
m

z
o
n
e
T
o

z
o
n
e
P
a
t
h

l
e
g
s
P
a
s
s
e
n
g
e
r

t
r
i
p
s
N
u
m
b
e
r

o
f

f
a
r
e

z
o
n
e
s
O
n
e
-
w
a
y

t
i
c
k
e
t

b
a
s
e

f
a
r
e

[
C
U
]
S
u
p
p
l
e
m
e
n
t

f
o
r

T
r
a
i
n

[
C
U
]
F
a
r
e

=

B
a
s
e

f
a
r
e

+

S
u
p
p
l
e
m
e
n
t

[
C
U
]
R
e
v
e
n
u
e

=

V
o
l
u
m
e

F
a
r
e

[
C
U
]
A Village X City Bus1
Train
1000 5 3.00 3.00 6.00 6000.00
A Village X City Bus1 1000 6 3.00 0.00 3.00 3000.00
A Village C Village Bus1 200 3 2.00 0.00 1.00 200.00
X City A Village Bus1 1000 6 3.00 0.00 3.00 3000.00
X City A Village Bus1
Train
1000 5 3.00 3.00 6.00 6000.00
X City C Village Train 5000 4 1.00 3.00 4.00 20000.00
X City B Village Bus1 2000 3 1.00 0.00 1.00 2000.00
C Village A Village Bus1 200 3 1.00 0.00 1.00 200.00
C Village X City Train 5000 4 1.00 3.00 4.00 20000.00
B Village X City Bus1 2000 3 1.00 0.00 1.00 2000.00
Total 62400.00
Table 236: Calculation of the revenues per path (PuT routes)
599 PTV AG

For revenue distribution the following formulas are applied
Share-FarePt = NumFarePt-PL / NumFarePt-Total
Share-PathLeg = 1 / NumPL
RevShare-PathLeg =(Share-FarePt W- NumFarePt + Share-PathLeg W-NumPL)
Rev-PathLeg = Rev-Fix + (Rev-PassTrip Rev-Fix NumPL) RevShare-PathLeg
The revenue distribution is also demonstrated with the example Example_LLE.ver. A zone-
based fare model was modeled there and the calculation of the input data required for revenue
distribution already demonstrated (see "Revenue calculation using the fare model" on
page 597).
Revenue distribution is only carried out for those paths which comprise more than one path leg.
In the example, this is the path from A Village to X City, where 1,000 passengers use the bus
and the train, and back. As the number of path leg fare points is 10 for both the bus (A Village
C Village) and the train (C Village X Town), a distribution factor of 0.5 results in each case.
Note: Revenue distribution does not regard how the revenue was calculated (fare model,
fixed revenue per passenger trip or fixed revenue per fare point).
NumPL Number of path legs in a passenger trip
NumFarePt-PL Number of fare points in a path leg
NumFarePt-Total Total number of fare points in the passenger trip
RevShare-PathLeg Share of the path revenue, which applies to the path leg
W-NumFarePt Weighting of fare points (length)
W-NumFarePt + W-NumPL=1.0
W-NumPL Weighting of path legs
Rev-PassTrip Revenue per passenger trip
Rev-Fix Revenue which is distributed to each path leg as a fixed amount
Rev-PathLeg Revenue which is distributed to the path leg
From origin zone 100 (A Village)
To destination zone 200 (X City)
Links in the course of Path 1 1 (Bus) -> 2 (Bus) -> 4 (Train)
Number of fare points on traversed
links
Link 1: 5 (Bus)
Link 2: 5 (Bus)
Link 4: 10 (Train)
Share-FarePt(Bus1)
Number of path legs of Path 1 2
Share-PathLeg(Bus1)
Revenue on Path 1 6000 CU
Weighting of fare points (length) 75 %
Weighting of path legs 25 %
Table 237: Revenue calculation for the path leg Bus1
5TP 5TP +
20TP
------------------------------ 0.5 =
1
2
---
600 PTV AG
If you want to return the revenues on the line level, the following calculation thus applies.
Another calculation example illustrates the calibration options (especially the definition of a
fixed amount for each path leg). Let the following network be the example network.
Illustration 193: Example network for fixed amount per path leg
Revenue Path Leg(Bus1)
Line FromZone ToZone PTrips Fare Revenue = PTrips Fare
BUS1 A Village X City 1000 3.00 3000.00
A Village X City 1000 6.00
A Village C Village 200 1.00 200.00
B Village X City 2000 1.00 2000.00
C Village A Village 200 1.00 200.0
X City A Village 1000 3.00 3000.00
X City A Village 1000 6.00
X City B Village 2000 1.00 2000.00
Total = 16400.00
TRAIN X City C Village 5000 4.00 20000.00
X City A Village 1000 6.00
C Village X City 5000 4.00 2000.00
A Village X City 1000 6.00
Total = 46000.00
Table 238: Aggregation of the path leg revenues to lines
Passenger trips 3
Total number of fare points 12
Share-FarePt(Bus1)
Table 237: Revenue calculation for the path leg Bus1
5TP 5TP +
20TP
------------------------------ 0.75
1
2
--- 0.25 +

6000 CU ( ) 3000 CU ( ) =
6000
1
2
--- 3000 =
6000
1
2
--- 3000 =
6000
1
2
--- 3000 =
6000
1
2
--- 3000 =
S1 S1 S4 S4 S3 S3 S2 S2
6 FP 2 FP 4 FP
Train Bus 2 Bus 1
2
12
------ 0.167 =
601 PTV AG
When using a fare model (see "Revenue calculation using the fare model" on page 597), the
distribution of supplements can also be influenced. With the option Distribute supplements
to transport systems you have the following possibilities:
If the option is selected, the supplement charged for the transport system is only distributed
to the path legs which are traversed by this transport system. This is how the supplement
is only distributed to the path legs, where the long-distance train is used, for example for a
connection where a local train without supplement and a long-distance train with
supplement are used.
If the option has not been selected, the supplement is distributed to all path legs according
to the distribution key, independent of whether the transport system, for which the
supplement was defined, is used for this path leg. This is how a regional train also benefits
from the supplement for a long-distance train, for revenue distribution, for example.
Share-FarePt(Train)
Share-FarePt(Bus2)
Number of path legs 3
Share-PL
Rev-PassTrip 3.00
Path leg Share per path leg Revenue per path leg
Bus 1 1.0 0.167 + 0.0 0.333 = 0.167 0.167 3.00 = 0.50
Train 1.0 0.500 + 0.0 0.333 = 0.500 0.500 3.00 = 1.50
Bus 2 1.0 0.333 + 0.0 0.333 = 0.333 0.333 3.00 = 1.00
Table 240: Revenue distribution W-NumFP = 1.0, W-NumPL= 0.0, FixSuppl = 0
Bus 1 0.5 0.167 + 0.5 0.333 = 0.250 0.250 3.00 = 0.75
Train 0.5 0.500 + 0.5 0.333 = 0.417 0.417 3.00 = 1.25
Bus 2 0.5 0.333 + 0.5 0.333 = 0.333 0.333 3.00 = 1.00
Table 241: Revenue distribution W-NumFP = 0.5, W-NumPL = 0.5 , FixSuppl = 0.00
Bus 1 0.5 0.167 + 0.5 0.333 = 0.250 0.20 + 0.250 (3.00 - 3 0.20) = 0.80
Train 0.5 0.500 + 0.5 0.333 = 0.417 0.20 + 0.417 (3.00 - 3 0.20) = 1.20
Bus 2 0.5 0.333 + 0.5 0.333 = 0.333 0.20 + 0.333 (3.00 - 3 0.20) = 1.00
Table 242: Revenue distribution W-NumFP = 0.5, W-NumPL = 0.5 , FixSuppl = 0.20
6
12
------ 0.5 =
4
12
------ 0.333 =
1
3
--- 0.333 =
602 PTV AG
An example illustrates the differences between both methods. There is only one fixed
supplement in the example. To make it easier, there is no distance-based supplement. The
base fare of the connection is 30.00 CU.
(*) The fixed supplement of the top-ranking TSys (ICE) is only charged once, in this case
7.00 CU.
(**) The supplement of 7.00 CU is only distributed onto both transport systems EC and IC,
because they have the same maximum rank. If for example, the IC had a rank 3 and a fixed
supplement of 3.00 CU, the EC would obtain the complete supplement of 7.00 CU, when
taking the rank into consideration and distributing by transport system.
7.6.7.5 Calculation of cost coverage
For cost coverage calculation, total revenues have to be compared with total costs. The
following output attributes are available.
For the application example, cost coverage data on line level is calculated as follows for Bus1
for example.
TSys
(#Rank)
Number of
fare points on
path leg
Distribution of
the base fare
[CU]
Fixed
supplem
ent [CU]
Transport system-based
supplement distribution
onto path legs [CU]
Distribution of the
supplement onto
all path legs [CU]
EC (#2) 100.00 10,00 7.00 (**) 3.50 2.33
IC (#2) 100.00 10,00 7.00 (**) 3.50 2.33
RE (#3) 100.00 10,00 0.00 0.00 2.33
Total 30.00 (*) 7.00 7.00 7.00
CostCov total Expresses the cost coverage in absolute numbers.
CostCov total = Revenue total (length proportional) - Costs
CostCov Percent [%] Expresses the cost coverage in percent.
Cost coverage per
passenger trip
Expresses the cost coverage per passenger trip.
This attribute is only available for the elements of the line hierarchy and
for PuT operators and transport systems.
Table 243: Indicators for the cost coverage calculation
Total revenue 16400.00 CU
Costs 36321.86 CU
CostCov total 16400.00 CU - 36321.86 CU = -19921.86 CU
Table 244: Cost coverage calculation from revenues and costs
CostCov [%]
Revenue tot (lenght prop)
Cost
-------------------------------------------------------------------- 100 =
CostCov PTripUnlinked
CostCovTot
PTripsUnlinked
---------------------------------------- =
603 PTV AG
7.6.8 Basic calculation principles for indicators
Here, the following indicator calculation principles are introduced.
Projection onto the analysis horizon (AH)
Aggregation along the line hierarchy (Aggregation of indicators on trip section level to
indicators of a higher level)
Temporal cut (Calculation of indicators for analysis time intervals)
Spatial cut (by territory)
Impact caused by couplings
Projection of additional attributes
7.6.8.1 Projection onto the analysis horizon
Using projection factors, the analysis period values of indicators can be extrapolated to any
user-defined analysis horizon. If your analysis period is one day and a service trip runs every
day throughout the year, you can for example use a projection factor of 365 to calculate the
revenue for the entire year. If the service trip only runs on weekdays, you can select a
projection factor of 260. Depending on the indicator to be calculated, the projection factor has
to either be set for the valid day or for the demand segment (Table 245).
i
The application example makes the difference between the projection factors on valid days
and those by the demand segment clear. For trip 135, passenger kilometers and service
kilometers are compared to each other.
CostCov Percent [%]
Passenger trips unlinked 8400
Cost coverage per passenger trip
= -2.37 CU
Table 244: Cost coverage calculation from revenues and costs
36321.86
16400.00
------------------------- 100 45.15 % =
-19921.86
8400
---------------------------
Indicator category Projection factor
Transport supply /
Valid day
Projection factor
Hourly costs / Valid
day
Projection factor by
DSeg
General indicators X
Transport supply X
Network performance X
Costs (apart from Cost Time) X
Cost Time X
Revenues X
Table 245: Which projection factor applies for the calculation of indicators?
Valid Day weekdays (Monday to Friday)
Table 246: Difference in the projection to AH for ServiceKm and PassengerKm
604 PTV AG
7.6.8.2 Example for temporal dependencies of indicators
For the projection to the analysis horizon, the indicators of the transport demand (network
performance, revenues) as well as the indicators of the transport supply (operating supply,
costs) and the hourly costs are each projected with a different projection factor. This takes the
fact into account that the transport demand, for example at the weekend, can decline more
severely than the transport supply. At the same time, there are higher personnel costs, i.e.
higher hourly cost rates on Sundays.
The projection factors for transport supply and hourly costs can be specified for each valid day
separately. In this way, for an analysis period of one week in August, not only can the indicators
of regularly occurring Valid Days be correctly projected to an analysis horizon of one year (for
example, Mon-Fri with factor 52), but also seasonally restricted Valid Days (for example,
Sat+Sun during the school summer holidays by applying factor 6).
The projection factors for the extrapolation of the network performance from the assignment
time interval to the analysis period or horizon are set separately for each demand segment.
Therefore, the projection factor from the assignment time interval to the analysis period
regards the relevance of the OD matrix content for the demand segment.
If the assignment time interval and the period of validity of the matrix cover the entire
analysis period, this factor is then equal to 1.
If the assignment time interval is shorter than the analysis period, then the projection factor
corresponds to the ratio between the demand in the analysis period and the demand in the
assignment time interval.
If the demand time series of the demand segment refers to only a part of the assignment
time interval, then the projection factor corresponds to the ratio between the demand in the
analysis period and that of the demand time series time period.
The following example shows how this kind of calculation can be used to save computation
time in case of homogeneous demand.
Example
The analysis period and the assignment time interval should each cover one week (Monday to
Sunday). The timetable services from Monday to Friday are identical. For the "commuters"
demand segment the demand from Monday to Friday may be constant and the same time
series may be applied on weekdays, whereas on the weekend there is no demand in this
segment. The demand of this demand segment is coded in the OD matrix of one day in
combination with the time series for 24h, beginning Monday at 0:00. Due to the time series,
only the trips which start on Monday are charged during assignment. In order nevertheless to
Projection factor Transport supply / Valid day 260
Service kilometers (AP) 7.5 km
Service kilometers (AH) 260 7.5 km = 1950 km
Projection factor Demand segment PuT 365
Passenger kilometers (AP) 397.5 km
Passenger kilometers (AH) 365 397.5 km = 145087.5 km
Table 246: Difference in the projection to AH for ServiceKm and PassengerKm
605 PTV AG
indicate correct weekly values as PuT volumes per analysis period, the following projection
factors are applied to the "commuters" demand segment.
The following example of a vehicle journey with two sections (illustration 194) shows the
calculation of selected operating indicators for the following analysis time slices.
the analysis period of one week
the analysis horizon of one year
an analysis time interval on Tuesday 7 8 a.m.
As shown in illustration 194 and Table 247, vehicle journey section 1 is served daily, whereas
vehicle journey section 2 is available only on Sundays and public holidays.
Illustration 194: Time-distance diagram for a vehicle journey with two vehicle journey sections
Projection from ... to ... Factor
Assignment time interval AP 5
Assignment time interval AH (= year) 5 52 = 260
VehJourney VehJournSect 1 VehJournSect 2
Valid Day Daily Sunday+Holiday
Projection factor Analysis Horizon 52 63
Departure 6:30
Arrival 7:30
Trip length 30 km 30 km 20 km
Trip length 6:30 - 7:00 10 km 10 km 0 km
SeatCap 200 100
Table 247: Further specifications for the vehicle journey with two VJ sections

t
s
0 km
7:00 8:00
10 km
20 km
30 km
6:00
1
2
606 PTV AG
Table 248 shows the calculation of the seat kilometers. This is done by multiplying the seating
capacity by the service trip length and then simply adding up the vehicle journey section data.
Compared to seat kilometers, the calculation of service kilometers (often termed load
kilometers or train kilometers) by simply adding up the vehicle journey sections is not
permitted. In this case, it must be realized that superimposed vehicle journey sections may
only be counted once. This is particularly important for the calculation of any track costs
derived from the service kilometers. Track costs are calculated on the basis of service
kilometers regardless of the train composition. In the projection to the analysis horizon,
however, different projection factors may arise for the vehicle journey sections. In this case a
maximum formation is taking place. In the example shown in Table 249, this is the case on
Sunday. The calculation of the service time is carried out in the same way.
Analysis period Mon-Sun
VehJournSect 1 200 seats 20 km 7 days = 28000 km
VehJournSect 2 100 seats 20 km 1 day = 2000 km
Total 30000 km
Analysis horizon
VehJournSect 1 28000 km 52 = 1456000 km
VehJournSect 2 2000 km 63 = 126000 km
Total 1582000 km
Analysis time interval Tue 7:00 8:00
VehJournSect 1 200 seats 10 km = 2000 km
VehJournSect 2 100 seats 0 km = 0 km
Total 2000 km
Table 248: Calculation of seat kilometers
Analysis period Mon-
Sun
Analysis horizon Analysis time period Tue 7:00-8:00
Monday 20 km 1 20 km 52 10 km 0
Tuesday 20 km 1 20 km 52 10 km 1
Wednesday 20 km 1 20 km 52 10 km 0
Thursday 20 km 1 20 km 52 10 km 0
Friday 20 km 1 20 km 52 10 km 0
Saturday 20 km 1 20 km 52 10 km 0
Sunday 10 km 1
+ 10 km 1
+ 10 km 1
10 km 52
+ 10 km MAX(52;63)
+ 10 km 63
20 km 0
Total 150 km 8,020 km 10 km
Table 249: Calculation of service kilometers
607 PTV AG
7.6.8.3 Aggregation along the line hierarchy
Internally VISUM adds based on the value calculated from the service trip section all
indicators along the line hierarchy (Internally here means, that not all indicators can be
displayed on service trip section level. The reason being saving the values in the memory
requirements). This also applies if indicators are evaluated by territory or time slice.
Illustration 195: Aggregation along the line hierarchy
For operators, aggregation is also carried out via the vehicle journey sections (because as an
option, each vehicle journey section can be assigned an operator). For the aggregation on
transport system level, the line values are added per transport system (because a transport
system has to be assigned to each line).
For the service kilometers of the transport system Train in the application example, the
calculation is as follows.
Illustration 196: Aggregation of the service kilometers from the trips onto the line
7.6.8.4 Temporal cut (Time cut)
The temporal cut is applied, if you want to calculate indicators for a certain analysis time
interval (see User Manual, Chpt. 4.2.2, page 824) or during the calculation of the indicators for
the analysis period. In the last case, the complete days of the analysis period are treated
Vehicle journey
Time profile
Line route
Line
Main line
A
g
g
r
e
g
a
t
i
o
n
608 PTV AG
internally the same as a time interval, which last from 12 pm to 12 am. The temporal cut is
carried out on the time profile.
For the time cut, the departing line route items are decisive. Indicators are always first
calculated on the trip section level and then aggregated along the line hierarchy (see
"Aggregation along the line hierarchy" on page 607). If a time interval lasts for example from
8 a.m. to 9 a.m. and a trip departs at 7:55 a.m., the line route item which departs at 7:55 a.m.,
is not included in the indicator calculation. If however, another trip departs at 8:55 a.m., this line
route item is still included in the calculation.
The division of link-related indicators is thus based on the acuteness of individual links. In the
case of trips exceeding a time interval limit for example, a time interval is assigned to the
values of those links whose FromNode is traversed within the time interval. For that purpose,
the passage times at each of the nodes and stop points crossed are interpolated from the run
times of the time profile first and then compared with the limits of the time intervals(see
"Interpolation of passage times (run times in minutes)" on page 608) . A calculation example
can also be found in a different place (see "Measurement of the transport supply" on
page 576).
Illustration 197: Interpolation of passage times (run times in minutes)
7.6.8.5 Spatial cut (Territory cut)
In principle, the calculation of the territory-specific portion is based on cutting the link.
Length-related and time-related indicators, which are calculated per link (for example
service kilometers), are summed up for the territory where the link is located in.
If a link traverses several territories, the indicators of territories is proportionally added
to the respective length shares, for length-related indicators.
If a link traverses several territories, the indicators of territories is proportionally added
to the respective time shares, for time-related indicators.
For indicators which are not calculated per link, such as the number of stop events in a
territory, this territory is summed up where the polygon lies.

B
Links with run times
Line route
Time profile
3 6 1 4
4 2 10
Line route with
interpolated run times
2 2 2 2 8
B
B
A
A
A
A
C
C
C
C
E
E
E
E
D
D
D
X
X
X
Stop point exactly
between B and C
4 * 3 / (3 + 6*0.5)
609 PTV AG
7.6.8.6 Partially traversed links
Partially traversed links are a special case. These are links with a stop point on the link, where
a trip ends or starts at this link stop point. For the calculation of some indicators, the link has to
be traversed by at least 50 %, to be included in the calculation. Which rule applies for which
indicator and network object, can be taken from the file IndicatorAvailability.xls. An example for
this are the service kilometers on the link. In the upper section of the illustration 198, the link is
only traversed by 20 %. The service kilometers on the link are then 0 km. In the lower section
of the illustration, the link is traversed by 80 %. The service kilometers on the link are then
8 km.
Illustration 198: Partially traversed links
7.6.8.7 Impact caused by couplings
For some indicators, coupled service trips are counted proportionally. This means, that two
service trips which are coupled, in the coupled section share the value of the indicator. The
Excel file IndicatorAvailability.xls provides an overview of the indicators to which this applies. If
indicators regard the coupled service trips only for certain network objects, this is additionally
noted in a comment.
The following example illustrates the influence of couplings. Couplings are taken into
consideration for service kilometers, for section service kilometers however, couplings are not
taken into consideration.
H1 H3 H2
Trip
20% 80%
Link 1: 10km
ServiceKm Link 1: 0km
H1 H3 H2
Trip
20% 80%
ServiceKm Link 1: 8km
610 PTV AG
Illustration 199: Influence of couplings on the indicator calculation
7.6.8.8 Projection of additional attributes
In addition to the pre-defined PuT operating indicators also user-defined indicators can be
extrapolated from the level of vehicle journey sections to higher levels of the line hierarchy
called Projection of additional attributes if required, they are returned by territory, too.
Each vehicle journey section attribute selected for the projection of additional attributes is
calculated according to the following algorithm.
Result attributes are created
For the network objects Service trip, Time profile, Line route, Line, Main line, TSys and
TerritoryPuTDetail it is checked if there is a numeric, editable attribute featuring the same
ID as the original attribute. If not, a user-defined attribute featuring that ID is generated
automatically. Code and name, too, are adopted from the original attribute. For the network
objects Vehicle journey section, Service trip, Time profile, Line route, Line, Main line, TSys
and TerritoryPuTDetail it is checked if there is a numeric, editable attribute featuring the
same ID as the original attribute but suffixed by "AH". If not, a user-defined attribute
featuring that ID is generated automatically. Code and name is each suffixed by "AH, too.
If the result attributes already exist, they will be set to zero.

Calculation at vehicle journey section level
It is assumed that the original attribute contains a value related to AP. At the vehicle journey
section the AH result attribute value is determined as follows.
ValueAH = ValueAP ProjFactorTransportSupply
Here, the projection factor specified for the Valid Day of the journey section is used for the
transport supply.
Calculation in the line hierarchy
The values of the original attribute are added up along the line hierarchy and allocated to
the respective result attribute there. The values of the AH result attribute of the vehicle
journey section are equally added up and allocated to the AH result attribute at each level .
Note: If the result attributes already exist, but are either not numeric or not editable, an error
message will be displayed and the projection of additional attributes will not start at all.
Unaffected hereof, the rest of the PuT Operating Indicators procedure, however, will still be
executed.
Trip 1
19km 2km
Trip 2
Coupl ing
(in associated time profile of the trips)
ServiceKmTrip 1: (19km / 2) + 2km = 11.5km
Section-ServiceKmTrip 1: 19km + 2km = 21km
ServiceKmTrip 2: (19km / 2) = 9.5km + 2km = 11.5km
Section-ServiceKmTrip 2: 19km
611 PTV AG
Territory cut
If the original attribute is a length-related attribute, the value of the vehicle journey
section is first distributed onto the traversed links in proportion to the line length. Then
the link values are intersected with territories as usual. Thus, the value of a link is added
to the share (link length in territory / link length) in the AP result attribute per object(s) of
the line hierarchy x territory.
If the original attribute is a time-related attribute, the value of the vehicle journey section
is first distributed onto the traversed links in proportion to the run times of the time
profile. Here, too, the link values are length-proportionally allocated to the territories
(see above).
If the original attribute is not length-related, its value will simply be added up for each
traversed territory.
The values calculated per vehicle journey section are each multiplied by the projection
factor AH for the transport supply (see above) and then added up equally in the AH result
attribute per object(s) of the line hierarchy x territory.

In the example Example_LLE.ver the network object vehicle journey section has the user-
defined attribute Revenue_per_PassKm. This reflects the ratio between revenue and
passenger kilometers. Projection to line data is carried out according to the following schema.
Illustration 200: Extended projection of attributes
Note: If the Init PuT Operating Indicators procedure is executed, the user-defined attributes
of the TerritoryPuTDetail network object, for example, Territory x TSys x Vehicle
combination, will be deleted (even if the LineCosting results are dropped for other reasons).
The other result attributes are kept since they might have existed before. If necessary, they
have to be deleted manually.
Vehicle journey
Time profile
Line route
Line
Main line
Trips 58 to 95 (38 trips): 0,38 GE/km each
Train 1 >; TP1: 19 * 0,38 GE/km = 7,22 GE/km
Train 1 <; TP1: 19 * 0,38 GE/km = 7,22 GE/km
Train 1 >: 1 * 7,22 GE/km = 7,22 GE/km
Train 1 <: 1 * 7,22 GE/km = 7,22 GE/km
Train: = 2 * 8,05 GE/km = 16,1 GE/km
Main lines do not exist
Trips 58 to 95, each exactly 1 VJI: 0,38 GE/km each
612 PTV AG
613 PTV AG
8 Environmental impact model and HBEFA
The VISUM add-on module Environment is used to calculate the environmental impact - noise
and pollutant emissions - caused by motorized traffic. Three procedures for calculating
environmental impact are available:
Noise-Emis-Rls90 (see "Noise volume" on page 613)
Calculation of noise emission levels in accordance with RLS-90 (see User Manual, Chpt.
8.4, page 1104).
Noise-Emis-Nordic (see "Noise volume" on page 613).
Calculation of noise emission levels in accordance with Nordic Council of Ministers (1996)
(see User Manual, Chpt. 8.4, page 1104).
Pollution-Emis (see "Air pollution emissions" on page 616).
Calculation of air pollution emissions in accordance with emission factors of the Swiss
Federal Office for the Environment (BAFU) (see User Manual, Chpt. 8.7, page 1107).
The HBEFA add-on allows you to calculate emission values by link, by territory and network-
wide in VISUM VISUM. The calculation is based on the Handbook Emission Factors for Road
Transport version 3.1 (see "Emission calculation according to HBEFA 3.1" on page 618).
Subjects
Noise volume
Air pollution emissions
Emission calculation according to HBEFA 3.1
8.1 Noise volume
To calculate noise volumes based on traffic volumes, VISUM offers the Noise-Emis-Rls90 and
Noise-Emis-Nordic procedures. The Noise-Emis-Rls90 procedure is based on the RLS-90 of
the noise reduction for roads by the German Federal Minister for Traffic, the Noise-Emis-
Nordic procedure on the Nordic Council of Ministers (1996) model.
The model is fairly simple but sufficient to identify relative variations, that is, how, where, and
to what extent traffic-routing and road construction measures affect traffic volumes and, as a
consequence, the noise situation of particular roads.
8.1.1 Noise-Emis-Rls90 procedure
The procedure determines the average emission level of long and straight roads in accordance
with RLS-90.For the calculation of Lm,E in decibels, VISUM considers the following
operations:
Calculation of the average level Lm(25) using equation (7), RLS-90.
M = relevant hourly traffic volume (car/h)

p = relevant HGV proportion in percent of total traffic (above 2.8 t total permissible weight)
( ) ( ) [ ] p 082 , 0 1 M lg 10 5 , 37 25 Lm + + =
614 PTV AG
Chapter 8: Environmental impact model and HBEFA
Determination of correction factor DStrO for different road surfaces in accordance with table
4, RLS-90. VISUM keeps the correction factors listed in this table as an ASCII file
RLS.DAT in the background.
Determination of speed correction Dv for permissible maximum speeds other than 100 km/
h using equation (8), RLS-90. For car v_0 is valid from 30 to130 km/h, for HGV from 30 to
80 km/h.
Determination of correction factor DStg for inclinations and gradients using equation (9),
RLS-90.
The final result for every active link is the emission level Lm,E which is calculated through
an addition using equation (6), RLS-90.
8.1.2 The Noise-Emis-Nordic procedure
This procedure is an enhancement of the Noise-Emis-Rls90 procedure for the Nordic Standard
in accordance with the Nordic Council of Ministers (1996). Its calculation is similar to the one
used in the Noise-Emis-Rls90 procedure.
8.1.3 Link attributes for noise calculations
The two noise calculation procedures require (Table 250) different input attributes. To
understand these input attributes please refer to the explanations and illustrations in the RLS-
90. The output value Noise is returned as a result.
Note: The correction factor DE which takes absorption characteristics of reflecting areas
into account is not calculated.
Stg
D
StrO
D
v
D
m
L
E , m
L + + + =
HGV share
(Input)
HGV-share p (above 2.8 t total permissible weight) of total traffic
Default: 0
Value range: 0 to 100
Slope
(Input)
Lengthways link slant g in percent for specifying correction factor DStg for
inclinations and gradients where the following rules apply:
DStg = 0,6 |g| -3 for |g| > 5%
DStg = 0 for |g| 5%
Default: 0
Value range: -50 to 50
Surface type
Surface type(EWS)
(Input)
For different road surface types, correction penalties are generated and added
in accordance with RLS 90, table 4. The respective data are stored in the
parameters file RLS.DAT (see "Parameters file RLS.DAT" on page 615).
Standard value: 1
Value range: 1 to 9
Noise
(Output)
Mean emission level Lm,E of long and straight roads in [dB].
Table 250: Link attributes for noise calculations
615 PTV AG
Chapter 8.1: Noise volume
Parameters file RLS.DAT
* Sur f ace t ypesper mi ssi bl e maxi mumspeed
*30 km/ h40 km/ h50 km/ h>= 60km/ h
* non- por ous
*cast - asphal t , asphal t concr et e
*Type 1
0000
*
* por ous cast - asphal t
* Concr et e
*Type 2
1. 01. 52. 02. 0
*
* Pavi ng wi t h
* l evel sur f ace
*Type 3
2. 02. 53. 03. 0
*
*ot her pavi ng
*
*Type 4
3. 04. 56. 06. 0
*
*ZTV Concr et e 93
*wi t h st eel br ush st r oke
*Type 5
0001. 0
*
*ZTV Concr et e 93
*wi t hout st eel br ush st r oke
*Type 6
000- 2. 0
*
*Asphal t concr et e 0/ 11
*Mast i x asphal t
*Type 7
000- 2. 0
*
*open por ous asphal t
*Gr ai n 0/ 11
*Type 8
000- 4. 0
*
*open por ous asphal t
*Gr ai n 0/ 8
*Type 9
000- 5. 0
The values apply to the correction penalties per surface type.
illustration 201 shows an example where noise calculation is illustrated as link bars according
to Noise-Emis-Rls90. In the User Manual you will find further information on implementation
616 PTV AG
Illustration 201: Illustration of noise volume as link bars
8.2 Air pollution emissions
In VISUM, road traffic air emissions can be determined on the basis of the calculation
procedure Pollution-Emis (based on emission factors of the Swiss Federal Office for the
Environment).
The calculation of the pollution emission values is carried out internally by the program on the
basis of direction; volume values for both directions are later added. The result is displayed as
a cross-section volume.
The emissions are calculated for every car and every truck (HGV), with every value multiplied
by the number of vehicles (link volume for HGVs or cars). These partial sums are then totaled.
8.2.1 Pollution-Emis procedure
This procedure is based on emission factors issued by the Swiss Federal Office for the
Environment (BAFU) for pollutants NOx, CO, HC and SO2, for both cars and HGVs. For each
pollutant, a regression curve with polynomes to the 5th degree is used.
Emiss:= a + b * v + c * v2 + d * v3 + e * v4 + f * v5
The parameters a,b,c,d,e and f of the polynome were determined separately for different
pollutants for cars and HGVs for the reference years 1990, 1992, and 2000 and are contained
in the parameter text files EMI1990.DAT, EMI1992.DAT and EMI2000.DAT. For the reference
year 1990, for example, the following values are used.
* I nput f i l e f or f l exi bl e emi ssi on f or mul as f or Swi t zer l and 1990
* They ar e pol ynome t o t he 5t h degr ee.
*
* a + bx + cx2 + dx3 + ex4 + f x5( t he number s ar e exponent i al )
Note: To illustrate the noise volume in traffic networks, we recommend a classification
according to the DIN standard 18005 Part 2 09.91.
617 PTV AG
Chapter 8.2: Air pollution emissions
*( x i s t he speed of car s or HGVs)
*
*a+bx+cx2+dx3+ex4+f x5
*NOx CAR
0. 758602. 8004e- 2- 9. 9187e- 41. 4276e- 5- 5. 6655e- 80. 0
*NOx HGV
24. 216- 0. 701941. 5878e- 2- 1. 5996e- 47. 1751e- 70. 0
*CO CAR
16. 425- 0. 383572. 8706e- 3- 4. 5425e- 60. 00. 0
*CO HGV
45. 380- 3. 07299. 7880e- 2- 1. 6116e- 31. 3138e- 5- 4. 1410e- 8
*HC CAR
2. 2155- 6. 6593e- 28. 7930e- 4- 5. 1330e- 61. 1381e- 80. 0
*HC HGV
46. 490- 3. 78590. 133822. 3153e- 31. 9258e- 5- 6. 1410e- 8
*SO2 CAR
101. 80- 3. 03094. 4557e- 2- 2. 8928e- 47. 7300e- 70. 0
*SO2 HGV
1980. 4- 87. 5642. 9120- 5. 0701e- 24. 3285e- 4- 1. 3577e- 6
Recent measurements have shown that actual emission values are generally overestimated by
1990 calculation factors, because the change in vehicle fleets (more vehicles have now been
equipped with catalytic converters) has contributed to decreasing volumes per vehicle. The
latest Swiss emission factors take this change into account with modifications for the years
1992 and 2000.
The polynome approximation of emissions relative to speed shows the following developments
for CO for the different reference years in illustration 202:
Illustration 202: Emissions relative to speed
8.2.2 Pollutant-Emis link attributes
For the emission calculation procedure Pollutant-Emis, the HGV share is required as input link
attribute. The link attributes (air pollution) in Table 251 are output as output values.
Car 1990
Car 1992
Car 2000
HGV (same val ues for al l years)
0,0
2,0
4,0
6,0
8,0
10,0
12,0
14,0
16,0
18,0
20,0
0,0
2,0
4,0
6,0
8,0
10,0
12,0
14,0
16,0
18,0
20,0
0 10 20 30 40 50 60 70 80 90 100 110 0 10 20 30 40 50 60 70 80 90 100 110
Speed km/h
CO emissi on vol ume i n g/km
618 PTV AG
illustration 203 shows an example where the nitrogen monoxide volumes are displayed as link
bars according to Pollution-Emis. In the User Manual you will find further information on
implementation (see User Manual, Chpt. 8.8, page 1108).
Illustration 203: Display of nitrogen monoxide volumes as link bars
8.3 Emission calculation according to HBEFA 3.1
This chapter describes the fundamental principle and the basics of the emission calculation
according to HBEFA (see User Manual, Chpt. 8.10, page 1110).
8.3.1 Fundamental principle
The HBEFA-based emission calculation procedure allows you to calculate emission values
HGV share
(Input)
Relevant HGV share in percent of total traffic (above 2.8 t total permissible weight)
EDat_NOx
(Output)
Nitric oxides in g/km
EDat_SO2
(Output)
Sulphur dioxide in g/km
EDat_CO
(Output)
Carbon monoxide in kg/km
EDat_HC
(Output)
Hydrocarbons in g/km
Table 251: Pollutant-Emis link attributes
Note: For the display of pollution emissions, we recommend the use of classified values.
619 PTV AG
Chapter 8.3: Emission calculation according to HBEFA 3.1
by link, by territory or network-wide in VISUM . The calculation is based on the Handbook
Emission Factors for Road Transport version 3.1. From the Handbook HBEFA 3.1:
"The Handbook of emission factors for Road Transport provides emission factors, i.e. the
specific emission in g/km for all current vehicle categories (PC, LDV, HDV and motorcycles),
each divided into different categories, for a wide variety of traffic situations."
8.3.2 Basics of the HBEFA calculation in VISUM
In VISUM the emission calculation according to HBEFA determines the desired emissions and
optionally cold start excess emissions. The traffic situation, volumes and fleet compositions are
taken into account. The traffic situation, volumes and fleet compositions are taken into account.
Emissions are calculated on the basis of links in VISUM. Emissions are not calculated for turns,
main turns, and connectors.
For a HBEFA-based emission calculation, you first need to define fleet compositions. The fleet
compositions suggested by HBEFA per country, calendar year and category (e.g. Car or HGV)
can be used as a basis here.
Then, the emissions are calculated with the HBEFA-based emission calculation procedure,
which can be calculated for either one or several demand segments at the same time.
The procedure can be calculated in two different ways:
statically (for analysis period and analysis horizon)
dynamically (additionally per analysis time interval)

Per demand segment, the volumes for warm emissions and cold start excess emissions stem
from a selectable attribute. This attribute is interpreted as volume with time reference analysis
period (AP). When calculating with AP-based volumes, the value is divided by the AP
projection factor and multiplied by the AH projection factor.
When calculating the fuel quality, as an indicator for the plausibility of the calculations, the
network-wide fuel consumption (quantity/[g]) collected by demand segment is converted into
the specific consumption ([l/100km]) separately by diesel and gasoline. First, the quantity is
divided by the density of the fuel (gasoline ca. 0,75kg/l, diesel ca. 0,83kg/l) and then related to
the mileage of the demand segment. The specific consumption by demand segment is
displayed in the Statistics > Emissions (HBEFA) list and saved to the trace file.
8.3.2.1 Basis for calculating warm emissions
The following data is determined for each link.
Fleet composition class to be applied:
The fleet composition class to be applied results from the HBEFA link class of the link type
and the link attribute Is Urban:
Note: The complete HBEFA Handbook is available on the website www.hbefa.net.
Note: You can calculate the dynamic variant, if volumes are available for individual analysis
time intervals.
620 PTV AG
Gradient class:
The gradient class results from the attribute Gradient based on the following classification:
Level of Service (LOS):
Depending on the parameter setting, the LOS is determined either directly from the content
of the selected attribute or based on a classification by the specified attribute regarding the
three specified class limits.
Static traffic situation (i. e. without the LOS share):
The urban/rural classification results directly from the link attribute Is Urban, the HBEFA link
class directly from the link type. The speed class is determined on the basis of the set link
attribute (default: v0), while only certain values are possible according to the traffic situation
scheme in HBEFA (depending on urban/rural and link class):
HBEFA link class Is Urban Fleet composition class to be
applied
HBEFA_Motorway-National or
HBEFA_Motorway-City or
HBEFA_Semi-Motorway
--- Highway
Other No Rural
Other Yes Urban
Note: If you use uniform fleet compositions for each demand segment, the fleet
composition for Urban is always applied.
Value range Gradient class
< -5 % -6 %
-5 % to below -3% -4 %
-3 % to below -1% -2 %
-1 % to below 1% 0 %
1 % to below 3% 2%
3 % to below 5% 4%
5% and more 6%
Note: If you calculate by time interval and the set subattribute type is AHPI with values for
time intervals, the LOS will be calculated per analysis time interval as well.
621 PTV AG
If there is a traffic situation whose speed does not vary by more than 5km/h, which matches
the characteristic urban/rural and the link class, it will be allocated. In the case of two such
traffic situations (e.g. 55km/h), the one with the higher speed will be allocated. If no traffic
situation fulfills this condition, the nearest traffic situation with the same link class will be
used.
If no traffic situation matches the specified combination of urban/rural and HBEFA link
class, the default traffic situation Rural/Motorway-National/80km/h will be used.
For the used fleet composition, the emission factor weighted by the static traffic situation, the
level of service and the gradient class will be multiplied for each pollutant to be calculated by
the value of the volume attribute (AP) specified for the demand segment and by the length of
the link. The result is the warm emission for this pollutant, this link and this demand segment
based on the analysis period. Multiplied by the respective projection factor, the amount is
saved in the respective link attribute (AP and AH) and added to the network-wide emission (AP
and AH).
If the calculation is additionally carried out per analysis time interval, the emission factor is
determined once per interval due to the interval-dependent LOS and multiplied by the volume
value for this interval and the length of the link. The result is then saved in the subattribute
associated with the analysis time interval and added to the network-wide time-dependent
emission.
Calculated pollutants
The following pollutants can be calculated in VISUM. The pollutants are divided into three
groups:
Group 1: Established measurement programs
Element Description
CO carbon monoxide
Fuel fuel consumption
Gasoline fuel consumption
Diesel fuel consumption
PM particle matters
HC hydrocarbons
622 PTV AG
Group 2: Complementary measurement programs and literature
Group 3: Indicative literature references
8.3.2.2 Basis for calculating cold start excess emissions
To determine the cold start excess emissions, firstly, the cold start emissions weighted over the
shares are calculated for each urban fleet composition used and for each pollutant. For this,
the supplements per pollutant and subsegment are requested from the HBEFA database.
The distribution of this emission onto links is done in two different ways, which can be switched
via attribute Calculate start excess based on routes at the origin zone:
Polygonal calculation
Calculation on routes

Polygonal, geometrical calculation
The idea of the geometrical calculation is that the start of a route is diffuse. In the model, it
begins at the origin zone and enters the link network via a connector node. Realistic routes,
however, begin at an unspecified nearby location in the network. This is where the cold start
excess emission originates, too. And this is used to avoid the calculation on routes as follows.
NO
x
nitrogen oxide
CO
2
reported carbon dioxide "reported", i.e. without the biofuel share in the fuel
CO
2
total carbon dioxide "total", computed as total CO
2
from fuel consumption
PN Particle number
Element Description
Pb lead
Benzene benzene
CH
4
methane
SO
2
sulfur dioxide
NO
2
nitrogen dioxide
NMHC non-methane hydrocarbon
Element Description
NH
3
ammoniac
N
2
O nitrous oxide
Note: The emission factors of the pollutants SO
2
, Pb and CO
2
reported are country specific
because they depend on the composition of the fuel. So far, only values for Germany can be
calculated in VISUM.
Note: In HBEFA, cold start excess emissions are not indicated for all subsegments. For
segments without an available excess, a cold start excess emission of 0 g/start will be
applied.
Element Description
623 PTV AG
For each origin zone, firstly, the absolute cold start excess emission is calculated as total over
the demand segments over the products from the value of the attraction attribute of the
demand segment multiplied by the share of cold start and the emission factor of the respective
pollutant for the fleet composition to be applied. This absolute emission per pollutant is
distributed length proportionally to all links that are not closed for the PrT which lie within a
radius of 1km around the convex hull of the connector node of the zone. Cold start excess
emissions which arise from different zones are accumulated.
Calculation on routes
In order to determine the cold start excess emissions on routes, all routes of the demand
segments to be calculated are evaluated from the origin to the destination. For each traversed
link, a cold start excess share A
P,S
is calculated as the integral of the decay function over the
link length. This share is multiplied with the volume of the route and the share of cold start of
the origin zone of the route. Any attribute, whose content does not have to correspond to the
total of the volumes of all routes, can be used as volume value when calculating the warm
emissions. In order to calculate meaningful cold start excess emissions anyhow, the value is
divided by the volume of the demand segment afterwards and multiplied by the value of the
volume attribute. That implies that the relation between the route volume and the link volume
multiplied by the value of the volume attribute yields the assumed route volume on the link,
which, however, does not have to be constant along the route any more. Per link, the value is
summed up over all routes. The evaluation of the routes can end as soon as the first four
kilometers of the route are traversed, because the decay function is constantly 0 thereafter.
After that, for each link, pollutant, and demand segment, the calculated value is multiplied with
the cold start excess emission factor of the fleet composition allocated for urban and projected
over AP and AH.
As in the case of the polygonal method, the calculated absolute emission of the zone is then
distributed proportionally to this indicator per link onto the links. Please note that this does not
yield the exact dynamic route volumes but an acceptable approximation. In order to use the
dynamic route volumes in the procedure, the traffic flow model of the used dynamic
assignment would have to be reproduced. The volume per analysis time interval calculated
from these dynamic route volumes during the assignment is used instead.
Like the other emissions, the cold start excess emissions are aggregated network-wide and
issued in the statistics list Emissions (HBEFA).

Note: If no routes are available for a demand segment and the calculation on routes is
demanded at a zone, no cold start excess emissions will be calculated for this zone. Besides
the explicit rejection of the routes, this is for example the case if you want to determine
emissions of service buses using a separate, artificial demand segment whose volumes
result from, for example, the number of service trips. Here, the omission of the cold start
excess emissions is in line with the fact that almost all of the trips are warm. The procedure
can, however, still be run.
624 PTV AG
625 PTV AG
9 Economic assessment according to EWS
The EWS-97 (Empfehlungen fr Wirtschaftlichkeitsuntersuchungen an Straen, 1997
English: Recommendations on economic efficiency analyses of roads) have been compiled by
the working committee on economic efficiency analyses of Forschungsgesellschaft fr
Straen- und Verkehrswesen (German Road and Traffic Research Association), being the
update of RAS-W-86 (Richtlinien fr die Anlage von Straen, Teil:
Wirtschaftlichkeitsuntersuchungen, 1986 English: Road design guidelines Part: Economic
efficiency analyses).
These recommendations are the basis for the economic assessment of investments in road
construction according to uniform standards. The results of economic efficiency analyses
support decision-making on whether a measure or which of several possible measures is to be
taken. Furthermore, decisions have to be made as objectively and as comprehensibly as
possible.
Subjects
EWS basics
EWS link attributes
EWS Costs
EWS Cost-benefit analysis
9.1 EWS basics
Economic efficiency analyses according to EWS-97 are based on the comparison of costs and
benefits which incur if a road construction measure is taken (planned case) or which can be
saved if the measure is not be taken (comparison case).
Utility
The EWS-97 assesses the impacts of the realization of road construction measures
considering the modification of the following benefit components (difference of the non-
investment costs).
Operating cost
Travel times
Accidental events
Noise volume
Pollutant volume
CO2 volume
Barrier effect vs. pedestrian crossing
Availability of space for pedestrians and cyclists
If the impacts of a measure are compared, the benefits may be positive (economic gains) or
negative (economic losses). The benefits are assessed separately by direction.
626 PTV AG
Chapter 9: Economic assessment according to EWS
Costs
The costs are broken down in two components.
Investment costs (costs for the construction or modernization of roads and of
compensational work).
Running costs (road maintenance costs)
Constructional maintenance (instant and small-scale measures)
Operational maintenance (cleaning, control and maintenance work as well as winter
gritting and snow-clearing services to ensure operational reliability)
Evaluation period and annuities
Illustration 204: Evaluation period and annuities
The evaluation period is 20 years. Time of evaluation is the 1st January of the year after
inauguration (in EWS module: reference year; (see "EWS Costs" on page 630)).
As a start the investment costs (EWS module: costs in the year of the due date; (see "EWS
Costs" on page 630)) incurring at different times or periods are accumulated or discounted to
the reference time or year (in EWS module: reference year; (see "EWS Costs" on
page 630)). Based on the various amortization time intervals constant annual amounts to be
invested (annuities) are calculated. This is done using annuity factors by means of which the
reference year costs are distributed over the evaluation period taking into account the
interests.
The benefits are determined for a representative year of the evaluation period (availability of
demand data) and therefore determined approximately constantly over the evaluation period
(benefit annuities). The overall benefit or the overall costs of the measures over the evaluation
period can be gained by multiplying the annuities by the corresponding cash value factor.
To determine the cost-benefit ratio the annual costs and benefits (annuities) are taken. Costs
and benefits are specified at price index 01/01/1995, hereby costs without VAT.
Cost-benefit ratio
Decision criterion for the economic efficiency of road construction measures is the quotient of
benefit and costs. In case of road construction investments the cost-benefit ratio (CBR)
20 years
E v a l u a t i o n p e r i o d
T
i
m
e

o
f

e
v
a
l
u
a
t
i
o
n
Investment costs in the year of the due date
Cost annuities
Accumulation
Discounting
B
e
n
e
f
i
t

f
o
r

a

r
e
p
r
e
s
e
n
t
a
t
i
v
e

y
e
a
r
Benefit annuities Benefit annuities
627 PTV AG
Chapter 9.1: EWS basics
specifies how many DM of benefit can be expected per DM of costs spent. If all kinds of
benefits and costs incurring additionally due to the construction measure are known, a CBR
1 provides evidence that the measure is worth to be taken. If different variants are available,
the variant featuring the higher CBR is the more advantageous one. The CBR is mainly
determined as annual CBR (see "Evaluation period and annuities" on page 626). To make the
determination of the cost-benefit ratio more transparent, the individual partial benefits of the
total cost-benefit ratio are apportioned.
Network delimitation
All coherent network segments for which the traffic volumes of comparison case and planned
case differ considerably (generally by more than 5% of the volume of the comparison case,
however, at least by 250 veh/24 h) belong to the studied network, this means the impact area
of the measure to be assessed.
Application areas and use constraints
EWS-97 are suitable for the assessment of the economic efficiency of road construction
measures within the framework of a comparison of variants (comparison of alternative designs
of one project, for example different alignments) or priority rankings (comparison of various
projects, for example different extensions of a road network).
However, it has to be noted that they are not necessarily suitable if major impacts on public
transport caused by planned road construction measures have to be taken into account.
If measures entail a major change of modal split, i.e. the distribution of trips on private
transport (PrT) and public transport (PuT) changes.
A road construction measure is to be compared with a construction measure for public
transport.
If benefits for public transport occur in form of modified vehicle and personnel costs as well
as running costs for rail-bound transport modes which can no longer be (EWS-97, p.7).
In those cases the proceeding and additional methods (for example, Verfahren der
Standardisierten Bewertung, Engl.: Standardized evaluation method) have to be determined
individually in cooperation with the parties involved.
Deviations from the EWS-97 guidelines for the implementation in the VISUM
EWS add-on module
The VISUM EWS add-on module has integrated the EWS edition 1997 into the VISUM
environment as accurately as possible. Minor corrections of the EWS guidelines have been
discussed and agreed with a member of the FGSV working committee in charge.
Hereby the following has to be taken into account.
Investment cost (EWS-97, pp. 29, 5.1)
At maximum 10 different items of investments can be specified for a road construction
measure. If this is not enough, investments featuring the same amortization periods can be
aggregated. EWS table 14 provides details on the breakdown of building activities.
Running cost (EWS-97, pp. 29, 5.2)
It is not possible to enter surcharges on the road type-dependent base values of
running costs (see EWS-97, table 15, p. 31) for extra expenditures (street lighting,
traffic signals, tunnels, winter services, cycle lanes). These costs can be input as
628 PTV AG
additional maintenance costs for the whole study network (see "EWS Costs" on
page 630).
The footnote concerning other extra-urban roads (EWS-97, table 15, p. 31), saying that
values are only applicable to the higher-order road network (others 30% less) has not
been implemented.
Changes of the accident event (EWS-97, pp.33, 6.3)
The proceeding described in section 6.3.3 concerning the adjustments to temporal
developments and local particularities has not been implemented.
The surcharges for road types 1.21 at RQ 26 and 1.31 at RQ 33 in table 16, p. 34, are
not taken into account.
Changes of noise volume (EWS-97, pp. 38, 6.4)
The difference in height between the points of emission and immission hm is directly
entered in VISUM as ImHght attribute ( see EWS-97, p. 40 equations (66) and (67)).
Changes of pollutant volume (EWS-97, pp. 40, 6.5). The alternating allocation of the middle
lane of road type 2.10 in table 41, p. 49, is not taken into account.
9.2 EWS link attributes
EWS-specific link attributes
Table 252 shows the EWS link attributes.
Notes: Working with VISUM users should pay attention to all differences between EWS
program module and EWS guidelines. In case of open questions please do not hesitate
to contact the PTV hotline.
The application of the EWS add-on module requires the detailed knowledge of EWS-97.
Gained results should be verified through plausibility checks.
DistanceBuil
Distance to building
properties (EWS)
(Input)
Distance of kerb to building properties [m]
Default: 0
Range: 0.00 to 1,000000.00
Build. type
Type of building
properties (EWS)
(Input)
Type of building properties
0 = none
1 = open
2 = closed
Default: 0
BuildHght
Height of buildings (EWS)
(Input)
Minimum average height of house fronts [m] (cf. EWS-97, equation 70)
Default: 0
Range: 0.00 to 1000.00
Residents
Residents (EWS)
(Input)
Number of residents concerned
Default: 0
Range: 0 to 100000
Table 252: EWS-specific link attributes
629 PTV AG
Chapter 9.2: EWS link attributes
Further link attributes
The following link attributes are also used with the VISUM Environment add-on module.
Gradient [%]
Longitudinal gradient of the lane (positive: uphill; negative: downhill).
Surface type
Road surface type (according to EWS-97, table 21, p. 39; see also RLS.DAT, section 8).
Share of HGV [%]
Share of HGV in total average daily traffic (see also default values of HGV shares
according to RLS-90 in EWS-97, table 20).
Noise immission height
Difference in height hm between noise emission and immission point in [m] (cf. EWS-97,
equation 66).
EWScategory
EWS category
(Input)
EWS road categories (according to EWS-97, table 20, p.39);
0 = motorways
1 = federal roads
2 = connecting roads (state, district, community)
3 = local roads
Default: 3
EWStype
EWS type
(Input)
EWS link type (according to EWS-97, table 6, p.16)
Default: 111
Sidewalk width
Sidewalk width (EWS)
(Input)
Sidewalk width for actual state [m]
Default: 0
Range: 0.00 to 99.99
Curvity
Curvature (EWS)
(Input)
Curvity as the total of all angles per kilometer [gon/km]
Default: 0
Range: 0 to 10000
Cycle lane width
Cycle lane width (EWS)
(Input)
Cycle track width for actual state [m]
Default: 0
Range: 0.00 to 99.99
Sidewalk width future
Future sidewalk width
(EWS)
(Input)
Sidewalk width for future state [m]
Default: 0
Range: 0.00 to 99.99
Cycle lane width future
Future cycle lane width
(EWS)
(Input)
Cycle lane width for future state [m]
Default: 0
Range: 0.00 to 99.99
Note: In VISUM immission height is not calculated according to EWS-97, equation (67),
but directly input by the user.
Table 252: EWS-specific link attributes
630 PTV AG
Furthermore, the following basic link attributes are required for calculations according to EWS.
Link length
permissible speed of vehicle groups (transport systems)
The volumes required for EWS can either be input as counted data or calculated by
assignment. On the one hand, it allows to use actual results gained from traffic counts and on
the other hand, the simulation of various variants based on the assignment methods integrated
in VISUM. The speeds relevant for the evaluation are calculated according to EWS-97, tables
11-13.
9.3 EWS Costs
Besides the EWS link attributes and the EWS parameters the costs equally have to be input for
the calculations according to ESW-97.
Investment costs
Additional annual maintenance costs
The total investment costs can be broken down to a maximum of 10 partial investments
(structures, components). Based on the amortization periods of the partial investments, the
time of inauguration as well as the usual interest rate for investment projects of 3 % will be
converted to annual investment costs (annuities).
VISUM determines the annual running costs taking the base values for comparison case and
planned case of the study network listed in EWS-97, table 15. , for comparison case and
planned case of the study network. Additional annual maintenance costs surcharges for extra
expenditures (for example street lighting, winter service) and other costs according to EWS-97,
table 15 (for example bridge and tunnel engineering) will also be added, if applicable.
9.4 EWS Cost-benefit analysis
(see User Manual, Chpt. 9.8, page 1131) automatically performs further calculations
comparing the results of comparison case and planned case either by comparison case and
planned case calculations carried through consecutively or by importing planned case and
comparison case files already containing VISUM EWS calculations.
Then all EWS calculations are output as annual values in a result table illustration 205.
Notes: Specification of the volume origin (assignment or AddValues) for EWS calculation in
EWS Parameters window.
System requirements
Volumes as link AddValues
Calculation of an assignment
The traffic volumes required for the EWS calculation have to be available as average daily
traffic ADT (cf. EWS-97, chapter 4.3.1). If demand matrices are not available as ADT, they
have to be adjusted accordingly. The conversion factor is specified in the EWS Parameters
window.
631 PTV AG
Chapter 9.4: EWS Cost-benefit analysis
Illustration 205: Depiction of the results in EWS window
The following calculation results all costs in million DM/year are output.
Running costs determined from the base values of EWS-97, table 15 including additional
annual maintenance costs (see "EWS Costs" on page 630) of comparison case and
planned case and their cost difference.
Investment costs (annuities; (see "EWS Costs" on page 630)) of comparison case and
Total costs, the sum of investment costs and running costs of comparison case and
Non-investment costs of comparison case and planned case, each in total and related to
the individual benefit components (operating cost, accidental events etc.) and their
difference (utility).
Share%: relative benefit of the individual benefit components related to the overall benefit,
for example according to table illustration 205:
CBR, overall cost-benefit ratio and relative cost-benefit ratio of the individual benefit
components, for example according to table in illustration 205.
The cost-benefit ratio allows a ranking of the different planning variants: construction
worthiness if CBRTotal 1.
56 . 6
36 . 14
94 . 0
2
2
% = = =
Total
CBR
CO
CBR
CO
Share
36 . 14
/ . 553 . 0
/ . 945 . 7
= = =
a DM Mio
a DM Mio
Total
CostDiff
Total
Utility
Total
CBR
94 . 0
/ . 553 . 0
/ . 521 . 0
2
2
= = =
a DM Mio
a DM Mio
Total
CostDiff
CO
Utility
CO
CBR
632 PTV AG
633 PTV AG
10 GIS functions
VISUM allows you to include data from geographic information systems (GIS) into your model.
Both ESRI shape files (file extension *.shp) and the Personal Geo Database (PGD) are
supported. VISUM also offers typical GIS functions such as the different objects or different
coordinate systems for georeferencing your network. Furthermore, functions for network
digitalization (GPS tracking) and visualization (legends, backgrounds, texts, polygons) are
offered, which make network data preparation for presentations easier.
Other GIS typical functions have already been discussed at some other point:
Integrating symbolic illustrations (see "Points of Interest (POI)" on page 59)
Showing and hiding layers (see User Manual, Chpt. , page 15)
Freely definable coloring for network objects (see User Manual, Chpt. 12.2, page 1253)
Subjects
Connection to the Personal Geo Database and GIS objects
Shape files as a GIS interface
Intersect
Coordinate systems
Processing the network display with graphic objects
GPS tracking
10.1 Connection to the Personal Geo Database and GIS objects
VISUM can temporarily connect itself with an ESRI Personal Geo Database (PGD) or a shape
file. This function can be useful for example, when a traffic modeler working with VISUM,
connects to a Personal Geo Database on the computer of a land use planner. The traffic
modeler can then take the required data from the Personal Geo Database of the land use
planner by means of intersection (see "Intersect" on page 638) and then cut the connection.
This process bypasses the need to import the file back to VISUM.

During the connection to the PGD, so-called GIS objects are created in VISUM. GIS objects
are POI-like network objects (see "Points of Interest (POI)" on page 59), which are only
available during a PGD connection. Analogous to POIs, GIS objects are organized into GIS
categories. A GIS object is either of type point, polyline or polygon.
GIS objects have a spatial reference. This can be used for example, to illustrate the following
objects in the VISUM network.
Schools, swimming pools, stops
Stretches of water, agricultural areas, planning districts
Note: To be able to use this function, you need a license for the program ArcGIS version 8.3
or higher.
634 PTV AG
Chapter 10: GIS functions
To create GIS objects in VISUM, you have to either select the PGD Feature Classes or Feature
Datasets for display or editing. The following objects are thus created in VISUM:
For each selected Feature Class of the Personal Geo Database, a GIS category is created.
For each Feature a GIS object
None of the coordinates transferred to VISUM are being converted. The GIS objects are
always removed again as soon as the connection to the PGD has ended. If you want to
permanently include GIS objects into the VISUM network, proceed as follows:
Convert the GIS objects into a shape file
Read the GIS objects as POI for example
The following applies during the Personal Geo Database connection:
Only key information on the objects is stored permanently.
Information on attributes of the category is available through an attribute interface.
Read and write access to the attributes is transferred directly to the database.
10.2 Shape files as a GIS interface
Shape files are a data format for geodata, which are used in most GISs. The data format is
especially suitable for the data exchange between VISUM and GIS. With VISUM you can read
and save shape files.

A shape file is not an individual file, but is made up of three files:
File *.shp for saving geometry data
File *.shx contains the geometry index to link to the attribute data
File *.dbf contains attribute data in dBase data format. You can assign the attributes
contained here a VISUM attribute, when reading the shape file (see User Manual, Chpt.
13.10.2, page 1445).
Shape files can contain points, lines or polygons (surfaces). Only one type of element can be
contained in a shape file.

10.2.1 Importing shape files
When importing shape files, the information contained in shape files is read in a VISUM
network. Which network it is imported to depends on the type of shape file (point, line or
polygon) and by which processing mode (additive or non-additive). An overview on which
shape file types are imported to which network objects is provided by Table 253.
Note: To save shape files you need the add-on module Shapefile converter.
Note: A technical description of the data format can be found on the Internet at www.esri.com/
library/whitepapers/pdfs/shapefile.pdf.
Link, Screenline,
Connector
Zone, Main zone, Territory,
Main node
Node, Detector, Count
location, Stop, Stop point
POI
Point X X X
Table 253: Reading shape files in VISUM network objects
635 PTV AG
Chapter 10.2: Shape files as a GIS interface

If you want to read existing node data as a stop points into the shape file, you have to first read
it as a node and then with the function aggregate node, create (see User Manual, Chpt.
2.11.14, page 193) stop points.
While reading polylines as links, you can create alternative directed links or links with both
directions. If a link is undirected, it has to be determined how to interpret each attribute.
Forward: direction from node ... to node
Backward: direction to node ... from node
Undir. value: 50% of the value for each direction
Symmetrical: equal value for both directions
While importing the shape file you can determine which source attribute (from the shape file)
should be assigned to which target attribute (an existing or user-defined attribute of the
selected network object). illustration 206 shows an example, where shape file data are read
as a link. The shape file contains the attributes STREET_NAM, LENGTH and LANE, which
allocate the VISUM link attributes Name, Length and Number of lanes.
Illustration 206: Source and target attribute allocations
Polyline X X
Polygon X X
Note: Creating POIs is only possible with additive reading of shape files, because a POI
category has to be specified, where the POIs can be included. At least one POI category has
to therefore be contained in the network, to read shape files as POIs.
Connectors, stop points, and count locations can only be read in additively.
Table 253: Reading shape files in VISUM network objects
636 PTV AG
Example applications
Reading shape files with a road network as links in VISUM. In VISUM a routing-enabled link
network is then available.
Reading cross-communities as territories
Reading schools as POIs
Reading land use as POIs
In addition to the import of shape files as VISUM network objects, you can also insert shape
files as background. This is how you can insert land use (for example residential areas,
industrial areas, commercial areas) to make your network more visible, for example. You can
thus insert multiple shape file layers into the network (for example a layer for industrial areas).
The drawing order of the layers and its color can be changed. illustration 207 shows an
example, where two shape files were integrated as a background with land use for residential
and commercial areas.
Illustration 207: Land use from two shape files as background
Note: The links have to first be enabled for transport systems.
637 PTV AG
Chapter 10.2: Shape files as a GIS interface
10.2.2 Exporting shape files
Exporting shape files can be useful for example, if you want to use calculation results such as
link volumes from a VISUM assignment in a GIS. Shape files can also be used to exchange
data with other users who only work with GIS and do not have a VISUM installation.
For network objects nodes, stop points, stops, links, zones, main zones, territories, line routes,
screenlines, connectors, POIs and detectors, binary shape files can be saved directly from
VISUM respectively. For each selected network object, a file with the extension *.shp, *.shx,
and *.dbf is saved. Additionally, VISUM creates a *.ctf file for each exported shape file. VISUM
renames attribute identifiers, which are longer than 10 characters, because shape files do not
support attribute identifiers with more characters. This is documented in the *.ctf file.
If a projection is defined in VISUM, VISUM creates a *.PRJ file for each network object type,
with the currently set projection (apart from during the setting VISUM, which means no
projection). This does not guarantee that when reading the shape file to another network,
which has a different projection of coordinates, the coordinates of this network remain
constant.
The Table 254 shows in which shape types the VISUM network objects are illustrated.
When exporting shape files, the following special cases have to be noted.
Note: Exporting shape files is only possible with the add-on module Shapefile converter.
Point Polyline Polygon
Nodes X
Main nodes X
Main node centroids X
Stop points X
Stops X
Links X
Zones X
Zone centroids X
Main zones X
Main zone centroids X
Territories X
Territory centroids X
Line routes X
Screenlines X
Connectors X
Count locations X
Detectors X
POIs X X X
Table 254: Illustration of VISUM files of shape types
638 PTV AG
Links
If links are saved undirected, only one object is created for both directions. The attributes
of the From node keep their name. Attributes of the opposite direction all start with an "R_".
If the option Directed is active, an individual object is saved in the shape file for each
direction.
Connectors
You can select whether the first point of the object should be the zone (standard setting) or
the node. For each single object the attributes of both directions are always stored.
Reverse attributes contain the entry R_ as prefix. The specified direction is always taken.
POIs
POIs can be point, polygon or polyline and are thus exported to three different files.
10.3 Intersect
One of the most important GIS functions is the intersect. This means the overlapping of two
subject levels of the same area section with the aim of gaining new information. To create a
demand model in VISUM, GIS structure data (such as the number of employees or the number
of pupils) can for example be read in a surface POI and these intersected with zones. The
result being the type of structure data for each zone (number of employees or pupils per zone)
in a VISUM attribute.
Intersections between network objects are possible in VISUM, so that no export in a GIS is
necessary for intersection operations. This can be used to link two network objects which
overlap each other (intersection) and saves the thus resulting information in a VISUM attribute.
The intersection area of two objects results from the spatial overlapping of both objects.
illustration 208 shows examples of overlapping network objects.
639 PTV AG
Chapter 10.3: Intersect
Illustration 208: Examples of overlapping network objects
Use cases
A typical use case for an intersection is the data import from a GIS.
There are land use data in GIS
Land use data are imported to VISUM using a shape file, which is read in a POI.
(Alternatively VISUM can be connected to a Personal Geo Database. Land use data in
VISUM are then available as GIS objects.)
The zone and an editable attribute are later selected as target object, to adapt the created
information.
Through the intersection of zones and POIs the result is the land use data per zone and can
for example be used in a VISUM demand model (for example the number of homes per
zone).
Intersection is not just confined to data exchange with GIS. Multiple application possibilities
also arise within VISUM. Some examples, which information can be obtained with an
intersection operation are introduced in the following.
640 PTV AG
Number of PuT passengers per zone (Table 255)
Number of inhabitants in the catchment area of line routes (Table 256)
Number of inhabitants in the catchment area of stops (Table 257)
Vehicle kilometers within territories (Table 258)
Zone number where the stop lies (Table 259)
Average number of PuT passengers at the stops of a zone (Table 260)
Intersecting zones and stop points: The passengers in a zone are calculated from the ZoneAddValue1 =
Sum of passengers at all stops in the zone polygon.
Table 255: Calculating the number of PuT passengers per zone
Intersecting line routes and zones: The inhabitants of a line route are calculated from
LineRoute.AddValue1 = Sum of inhabitants in zones within a 500m buffer around the line route.
Table 256: Calculating the number of inhabitants in the catchment area of lines
641 PTV AG
Table 258: Calculating the vehicle kilometers within territories
Intersecting stops and zones: The inhabitants of a catchment area of stops are calculated from
Stop.AddValue1 = Sum of inhabitants in zones within a 500m buffer around the stop.
Table 257: Calculating the number of inhabitants in the catchment area of stops
Intersecting territories and links: The vehicle kilometers in a territory are calculated from
Territory.AddValue1 = Sum of VehicleKm PrT via all links in a territory.
642 PTV AG
Table 259: Calculating the zone number where a stop point lies ()
The target attribute values can either be calculated as a sum, mean value, minimum or
maximum of the source attribute values. If for example you do not want to calculate the total
number of PuT passengers per zone (Table 255), but the average number of PuT passengers
at the stops of a zone, proceed as described in Table 260.

Buffer
To carry out intersections, at least one involved network object type has to be two-dimensional.
To obtain this, a buffer can be created around a network object.
Intersecting stop points and zones: In which zone a stop point lies, is calculated from
StopPointAddValue1 = smallest zone number of the zone where the stop point lies (Please note that the
minimum is selected here, because theoretically, a stop point could lie in two zones, if its polygons
overlap. One of the other three functions, however, could also be selected).
Intersecting zones and stops: The average number of passengers at stops in a zone is calculated from
the ZoneAddValue1 = Average number of departures at all stops within the zone polygon.
Table 260: Calculating the average number of PuT passengers at the stops of a zone
Note: If you want to calculate the number of source objects per target object, select the
attribute 1.0 of the source object .
643 PTV AG
A buffer assigns an area to a point object, line object or a polygon. The resulting area is
intersected along with the actual network object. An object point thus becomes a two-
dimensional object when calculating the intersection.
The buffer is not defined based on the polygon centroid, but on each point of the polygon. This
means, that the buffer is also placed around the polygon like a belt.
Source or target objects are first inflated by the set buffer size(s). The proportion is then
calculated by which the target buffer overlaps the source buffer(s). Together with the attribute
value of the source object, this share then enters the attribute value of the target object.
The buffer operation (obj, radius) assigns the area (buffer) resulting from all points that have a
distance radius to a point of obj to the particular object. Radius = 0 results in the obj itself. In
the case of buffer polygon objects, polygons plus their buffers are intersected.
Intersections
There are three types of intersections:
Surface with surface
The intersection of two polygons is defined as usual.
Surface with point
If a surface is intersected with a point, the attribute value of the point is counted 100%, if
the point lies within the polygon. Otherwise it is counted with 0%.
Surface with line
The intersection of a surface with a line object is the share of the line object within the
surface.
The polygon content Content(P) of a polygon is defined as usual. The following also applies:
For line objects obj Content(obj) = Length(obj) is defined.
For point objects obj Content(obj) is defined as infinitesimal > 0. An infinitesimal number
is a number whose absolute value is greater than zero but less than any positive real
number be it ever so small. Content defines the overlapping share of objects. A source
polygon P2 overlaps for example, the target polygon P1 with the following share.
.
If a buffer > 0 is assigned to a point or line object, it turns into a polygon.
Share is then defined as follows:
2 1 F F
) 2 (
) 2 1 (
) 2 , 1 (
P Content
P P Content
P P Share

=
=
pg p
pg p
pg genPoly p Po Share
1
0
) , int (
) , int ( ) int , ( pg genPoly p Po Share p Po pg genPoly Share =
pg" in l " ) , ( length of Share pg genPoly l Link Share =
644 PTV AG
Intersection then results in:
with P1 = buffer(origobj, targradius), P2 = buffer(origobj, origradius).
The following examples show the effect of the intersect operation in VISUM.
Illustration 209: Intersecting three polygon objects with a link buffer
In illustration 209, surfaces are intersected with surfaces. The intersection of two polygons is
defined as usual.
Prorated intersection of polygon and link buffer (1)
Polygon is located inside of link buffer - intersection of 100% (2)
Polygon is located outside of link buffer - intersection of 0% (3)
Note: The share of a point object equals 1 if it lies within the polygon, 0 if it is positioned
outside of it. A line object has a share x of a buffer if x = length of the section contained in the
buffer / total length.

=
l l Links
l l Links
l Length
l Length pg l Share
pg genPoly l Polyline gen Share
) (
) ( ) , (
) , (
) , ( l e genPolylin pg genPoly Share
) , ( pg genPoly l e genPolylin Share =
) 2 (
) 2 1 (
) 2 , 1 (
pg Content
pg pg Content
pg genPoly pg genPoly Share

=
( ) ) 2 , 1 ( ) ( ) arg ( P P Share origobj OAttr Aggr obj t TAttr
origobj
=
(1)
(2)
(3)
645 PTV AG
Illustration 210: Intersecting point objects with a polygon
In illustration 210, for those point objects outside of the polygon, intersection results in 0%, for
the three point objects inside of the polygon, intersection results in 100%. If 1.0 is selected as
source attribute, all stops (source object) per zone (target object) are counted here for example
(since value of source object = 1.0).
Illustration 211: Intersecting point objects with a buffer polygon
In illustration 211, for those point objects outside of the buffer polygon (= polygon + buffer),
intersection results in 0%. The intersection share within the buffer polygon is 100% for all point
objects. Six points are thus intersected with 100%.
Illustration 212: Intersecting point object buffers with polygons

1
2
3
4
646 PTV AG
If point objects are intersected with polygons, the intersection share of a buffer results per
polygon from the position of the buffer in the respective polygon. In the illustration 212, two
point object buffers with 100% share are intersected and one point object buffer prorated (its
remaining shares intersect with polygon 2 and 3) for polygon 1.
If a polygon is positioned exactly next to an adjacent one and a buffer is defined as > 0, point
objects within the overlapping area will be counted twice, because the polygon buffers overlap
each other and the point object lies within two polygons with buffers. The resulting number of
point objects regarded for intersection is then greater than the actual number of point objects.
10.4 Coordinate systems
When creating networks, components from different GIS sources are often combined, which
partially refer to different coordinate systems. To make the data consistent a coordinate
transformation is necessary. VISUM supports you with this task with the following functions.
The user can optionally specify that all coordinates in the current network belong to a
predefined coordinate system (see User Manual, Chpt. 10.1.1, page 1137).
The coordinate system can be changed in VISUM. You can automatically transform (see
User Manual, Chpt. 10.1.1, page 1137) the coordinates of the current network.
If data are imported, which apply to another coordinate system than that for the current
network, VISUM automatically transforms the imported coordinates into the system of the
current network.
There is an option to switch from the default VISUM to a predefined coordinate system. VISUM
offers a selection of coordinate systems, which are provided as files with the extension *.prj in
the directory ...VISUM115\EXE\PROJECTIONS. This file format is Well-Known-Text-Format in
ESRI version.

In VISUM, a difference is made between geographic coordinate systems and projected
coordinate systems.
In geographic coordinate systems, the coordinates are displayed as spherical coordinates with
geographic length and width. They are measured as an angle from the earth's center to a point
on the earth's surface (for example 47 6 northern latitude, 12 27 eastern longitude). In
comparison, the coordinates of the earth ellipsoid is projected to a level, for plane coordinate
systems. A location on earth is therefore distinctly determined as an X and Y coordinate on the
level. The following example in VISUM shows two projection files for a planar and a geometric
coordinate system.
Note: You can optionally specify, whether you want to work with a current projection in your
project. It is usually sufficient to keep the standard setting ("VISUM"). In this case coordinates
in VISUM do not apply to any current projection, but are illustrated "uninterpreted" in a
rectangular system. If, however, original files are specified in a certain projection and are
imported to a network, where no projection has been selected, the display is distorted. In this
case select the suitable projection.
647 PTV AG
Chapter 10.4: Coordinate systems
Example for planar coordinate system (WGS 1984 UTM Zone 48N.prj)
Example for geometric coordinate system (Deutsches Hauptdreiecksnetz.prj):

VISUM manages coordinate systems in the following file types: Depending on the file type,
coordinate information is saved or imported differently.
PROJ CS[ " WGS_1984_UTM_Zone_48N" ,
GEOGCS[ " GCS_WGS_1984" ,
DATUM[ " D_WGS_1984" ,
SPHEROI D[ " WGS_1984" , 6378137, 298. 257223563] ] ,
PRI MEM[ " Gr eenwi ch" , 0] ,
UNI T[ " Degr ee" , 0. 017453292519943295] ] ,
PROJ ECTI ON[ " Tr ansver se_Mer cat or " ] ,
PARAMETER[ " Fal se_East i ng" , 500000] ,
PARAMETER[ " Fal se_Nor t hi ng" , 0] ,
PARAMETER[ " Cent r al _Mer i di an" , 105] ,
PARAMETER[ " Scal e_Fact or " , 0. 9996] ,
PARAMETER[ " Lat i t ude_Of _Or i gi n" , 0] ,
UNI T[ " Met er " , 1] ]
Table 261: Planar coordinate system
GEOGCS[ " GCS_Deut sches_Haupt dr ei ecksnet z" ,
DATUM[ " D_Deut sches_Haupt dr ei ecksnet z" ,
SPHEROI D[ " Bessel _1841" , 6377397. 155, 299. 1528128] ] ,
PRI MEM[ " Gr eenwi ch" , 0] ,
UNI T[ " Degr ee" , 0. 017453292519943295] ]
Table 262: Geometric coordinate system
Note: Please note, that in the actual file *.prj the projection properties which are written down
row by row, have to be successive (in a row). Detailed information on how to create
projections can be found on the ESRI homepage (for example at www.support.esri.com/
index.cfm?fa=knowledgebase.techArticles.articleShow&d=14056).
File type Write Read
*.ver
Version file
All attributes of the current
coordinate system are saved.
All attributes of the current coordinate system
are read in. If the name of the system is not
found in the list of predefined systems, it is
added to the selection. A *.prj file is not created.
*.net, *.mdb
Network file
Database
All attributes of the current
coordinate system are saved.
If not read-in additionally, the file is read like a
version file, in case the network parameter block
is missing, the standard setting (VISUM) is
applied. If read-in additionally, the network
parameters block is read-in in case it exists and
is enabled (see User Manual, Chpt. 1.3.3.3,
page 41).
*.shp
Shape file
In addition to the shape file, a
*.prj file with the currently set
projection is created if it differs
from the standard setting
(VISUM).
If a corresponding *.prj file exists for a shape file,
it is used as projection and transformed into the
currently set projection if applicable. If it does not
exist and the existing network has a coordinate
system, the user selects a coordinate system
648 PTV AG
10.5 Processing the network display with graphic objects
VISUM offers many possibilities to process your network model for print-out or presentations.
Furthermore, the clarity of your network can be improved, by providing additional information,
such as texts or borders of areas. This is done with so-called network-independent graphic
objects. In contrast to network objects, network-independent graphic objects are not part of the
network model, which means they have no influence on the calculations carried out by VISUM.
In addition to the network-independent graphic objects, you have the possibility to insert a
legend, using a legend assistant. The following functions are available:
Inserting texts (see "Texts" on page 648)
Automatic creation of a legend (see "Legend" on page 648)
Inserting polygons (see "Polygons" on page 652)
Inserting background graphics (see "Backgrounds" on page 649)
10.5.1 Texts
Texts serve to additionally label network displays. There are two text types:
Background texts
Texts which are inserted into the network display
Legend texts
Texts which are inserted into a legend

10.5.2 Legend
With the legend additional information on illustrating and describing the network, can be output
in the VISUM network display. Legends are created with the Legend Wizard which enables
users to select the network objects to be listed and to set parameters for the display. The
wizard automatically generates a legend that matches those settings. Furthermore, space can
be made in the legend for user-defined complements. Externally prepared graphics can for
example be inserted there (illustration 213).
*.inp
VISSIM network
The coordinates are written to an
*.inp file without further
transformation.
not applicable
*.hgr
Background file
not applicable Background files are not adjusted.
File type Write Read
Note: Graphic texts are network-independent graphic objects and therefore be differentiated
from labels of network objects and labels for plot output.
649 PTV AG
Chapter 10.5: Processing the network display with graphic objects
Illustration 213: Legend with user-defined texts
10.5.3 Backgrounds
You can include many different graphic formats as a background for your network display. Both
vector graphics, for example *.shp or *.dxf and raster graphics, for example *.jpg, *.bmp or *.sid
are supported. Including backgrounds is ideal to better create a network display and add
graphical information to scale. This is how a zoning plan or a city map can be applied to the
background of the network display for example.

Backgrounds in graphics formats (Table 263) supported by VISUM can be freely scaled by the
user and placed where required in the network display. This means, that position and size are
determined via virtual, modifiable coordinates. It is possible to put several backgrounds on top
of each other. Their order of display can be changed by the user. illustration 214 shows a
network section without background. Only the link network is displayed. Backgrounds with land
use were inserted in the same network background in illustration 215.
Note: Backgrounds can only be inserted with add-on module Background.
650 PTV AG
Illustration 214: VISUM network display without background
Illustration 215: VISUM network display with background
651 PTV AG
Chapter 10.5: Processing the network display with graphic objects
10.5.3.1 Supported background formats
Table 263 outlines the most important graphic formats, which can be imported into VISUM via
graphic object type backgrounds.
File type Description
*.bmp (dib) Bitmap: pixel-based Windows standard format
*.wmf (emf) Windows Metafile: both vector- and pixel-based Windows graphic format (standard and
enhanced format)
*.gif Graphics Interchange Format: pixel-based standard format by Compuserve for internet
applications
*.jpg Joint Photographic Experts Group: standard pixel-based format for internet applications
developed by an ISO experts group
*.jp2 The JPEG2000 format also published by Joint Photographic Experts Group. Compared to
JPG, this format offers a better compression rate and can also receive meta data.
*.png Portable Network Graphics: License-free raster graphics format for Internet applications.
It was developed by the World Wide Web Consortium (W3C) to replace GIF and JPG.
*.psd Photoshop: Popular pixel-based format by Adobe for professional image processing on
PC
*.tif Tagged Image File: pixel based default format for DTP and scanner applications; also with
CCITT compression
*.tga Targa: Pixel-based format by Truevision for professional image processing on
Workstations
*.dwg A CAD format developed by Autodesk for CAD software AutoCad. The DWG format today,
is a de facto standard for CAD data exchange and the most commonly used drawing data
format.
*.dxf Drawing Interchange Format: A vector graphic format developed by Autodesk, for CAD
data exchange, which was developed for the CAD program AutoCAD. A *.dxf file writes a
CAD model (for example a technical drawing) as text according to the ASCII standard.
*.ecw Enhanced Compression Wavelet: ECW is a raster graphic format, which allows very high
compression rates. It is therefore ideal for saving aerial photographs and satellite images.
*.shp Shape files are data format for geodata, which are used in most GIS. The data format is
ideal for including GIS data in VISUM (see "Shape files as a GIS interface" on page 634).
*.sid Multiresolution seamless image database
MrSID is a compressed format for raster graphics. It is ideal for cartographic data and
satellite images.
*.svg Scalable Vector Graphics
Standard for describing two-dimensional vector graphics in the XML syntax. The main
language volume can be displayed by the most used web browsers without additional
plug-ins (for example Firefox). A plug-in such as the SVG Viewer by Adobe allows the
display on the Internet Explorer.
Table 263: Background formats supported by VISUM
652 PTV AG
10.5.3.2 Automatical positioning of the background in the network
with World files
If a raster graphic background is to be included in VISUM, georeferencing the background in
the network can be executed automatically, if in addition to the actual graphic file (for example
Background.jpg) a so-called World file (for example Background.jpw) is available, which
contains the data for georeferencing the image file. If a World file is available, this makes the
exchange and including backgrounds much easier, because the background is automatically
inserted in the right position in VISUM. The effort for vernier adjustment of the background
does therefore not apply.
A World file contains the transformation information used by the image, for the reference to
world coordinates. The format was specified and introduced by ESRI. The naming convention
for World files provides, that the last letter of the file ending of the graphic file is replaced with
a w, the rest of the file name corresponds to the respective graphic file (if the graphic is named
Map.tif for example, the respective World file is then named Map.tiw). A World file describes
the coordinates, the scale and the rotation of the background.

Each World file has six rows. Table 264 shows an example for a World file.
Row 1: Parameter A pixel size in x direction
Row 2: Parameter D rotation about y axis
Row 3: Parameter D rotation about x axis
Row 4: Parameter E pixel size in y direction
Row 5: X coordinate of the upper left pixel of the background
Row 6: Y coordinate of the upper left pixel of the background

10.5.4 Polygons
The polygons of the Background add-on module are graphic objects which facilitate the free
design of drawings. Polygons can be edited in many ways:
Drawing lines or areas
Choice of color
Position of lines and line types
Patterns for areas
Note: World files do not contain a reference to a coordinate system.
32, 0
0, 0
0, 0
- 32, 0
691200, 0
4576000, 0
Table 264: Example for a World file
Note: Georeferencing and thus creating the World file can be executed with GIS software (for
example ArcGIS by ESRI). Because the World file is a text file, it is theoretically possible to
create it yourself in the text editor, if the necessary information is known.
653 PTV AG
Chapter 10.6: GPS tracking

10.6 GPS tracking
If a GPS receiver is connected to your PC, you can display the current position in the network
graphic. With tracking switched on, the network graphic display is then updated in user-defined
time intervals (see User Manual, Chpt. 10.10, page 1181).
The function requires a connection via a serial interface. Receivers with a Bluetooth or USB
interface can also be used, if they emulate a serial interface. You can apply these functions to
digitalize links for example.
Each time the updating time interval has expired, the marking bitmap will be refreshed,
however, only if a GPS signal has actually been received. A GPS signal accompanied by a
warning (for example due to bad transmission or incorrect conversion of the coordinates) will
be drawn in Marking1 color (see User Manual, Chpt. 12.2, page 1253). The position acquired
by the GPS receiver (length, width) will always be transferred (see "Coordinate systems" on
page 646) into the current projection of the network. If no projection has been set, the position
is taken over directly. All that has to be noted is that the network coordinates correspond to the
actual geographical position.
Note: Polygons can only be inserted with add-on module Background.
654 PTV AG
655 PTV AG
11 Interactive analyses
VISUM offers different functionalities which you can use to interactively evaluate your traffic
model. These can be used to analyze PrT as well as PuT. The following interactive analyses
are available.
Subjects
Flow bundles
Isochrones
Shortest path search
11.1 Flow bundles
Flow bundles filter loaded paths determined in an assignment by a range of criteria. Loaded
paths are the result of assignment calculation and are characterized by the following
properties.
They consist of a route path from an origin zone to a destination zone.
They have a transport system type (PrT, PuT or PuT-Sys).
The show a volume (passengers, vehicles).
Flow bundles consist of all paths traversing the network objects marked for flow bundle
calculation. Marked network objects thus constitute the path filter criteria of a flow bundle.
Below, you will find out which filter criteria can be used in detail. Table 265 displays the
principle of the flow bundle. The left figure shows all paths found in the assignment and the
right one shows paths which lead via the marked link.
Flow bundles Filtering paths from the assignment according to different criteria (for example,
all paths which lead via a certain link)
Isochrones Analysis of the accessibility of network objects. Network objects which are
available from one or several network objects in the same time are colored with
the same color (for example, all locations which can be reached in 5 minutes by
foot from a node).
Shortest path search Searching the shortest path between zones, nodes or main nodes according to
different criteria (for example distance)
656 PTV AG
Chapter 11: Interactive analyses
The flow bundle can be displayed graphically in the network editor (see User Manual, Chpt.
11.1.4, page 1192) or output as a list (see User Manual, Chpt. 12.1, page 1227).Using PuT
assignment as an example illustration 216 displays the flow bundle paths in the PuT path legs
list. In the graphic display, the path courses highlighted in color and the respective flow bundle
volumes for each traversed link describe the spatial and quantitative distribution of traffic of the
specified flow bundle.
Illustration 216: Display of the flow bundle paths in the PuT path leg list
The flow bundle type is specified through the network object type selected:
All PrT paths (displayed as volume bars) Filtering all PrT paths, which lead via the marked
link, through the definition of a flow bundle.
Table 265: The flow bundle as path filter
Note: To be able to display a flow bundle, an assignment has to be calculated and the paths
saved. You can save paths in the PrT (see Basics, Chpt. 5.1.2, page 849) and in the PuT (see
Basics, Chpt. 6.1.1.2, page 944).
657 PTV AG
Chapter 11.1: Flow bundles
Flow bundles based on nodes, main nodes, stops, stop points or stop areas (marking
nodes, main nodes, stop points, stop areas or stops)
Link flow bundle (marking links)
Zone and main zone flow bundle (marking zones or main zones)
Traffic type flow bundle (by setting certain links or time profiles as passive)
The flow bundle can be created by marking one or more objects of a network object type. It can
also be determined by any combination of marked network objects of different network object
types (see "Combination of flow bundle criteria" on page 662).
11.1.1 Flow bundle definition by selecting network objects
Flow bundles are defined through the selection of network objects or by selecting the types of
traffic (combinations of this criteria are also possible). This section describes the
characteristics of flow bundles, which are calculated by marking network objects.
Node flow bundle (PrT and PuT)
The node flow bundle outputs all paths which lead to the marked node(s). In PrT you have to
select demand segments, whose paths should be considered (the assignment result and thus
the paths are available separately for each demand segment).
A selection of the demand segments is also necessary in PuT. In addition, you can extend the
filtering of paths by further criteria. A PuT supply selection can be made on different levels,
from transport system to line route, service trip and operator. A path is only contained in the
flow bundle, if it traverses the selected network object (for example a stop point) with exactly
the specified PuT supply. Depending on the network object type, the definition of "traversed"
differs. At a zone of the traffic type origin traffic, a condition is, for example, set at the first PuT
path leg of the path via the PuT supply filter.

The filter requirements which result from the selection of the network object and the definition
of the additional requirements for PuT network objects both have to be fulfilled at the same time
(AND THEN link). In the following example (see "PuT node flow bundle with additional filter
criteria for lines" on page 658) all paths are contained in the flow bundle, which traverse the
node 100001 and use line 002 on at least one path leg. Line 002 does not have to be used on
the entire path. It is sufficient if line 002 is traversed on one of the path legs, see
illustration 218.
Notes: If a flow bundle is active, the trips belonging to the flow bundle can be saved as a flow
bundle matrix.
The flow bundle considers the active settings of the OD pair filter. This makes flow bundle
analyses for particular types of zones (for example, only internal zones) possible.
Note: For the definition of these additional filter criteria, only those network objects can be
selected, which are actually traversed by the selected network object. If, for example, the
node k marked for the flow bundle is not traversed by line 002, the line is therefore not
available.
658 PTV AG
Illustration 217: PuT node flow bundle with additional filter criteria for lines
Illustration 218: Some of the paths which traverse node 100001 and use line 002
Main node flow bundle (PuT only)
The main node flow bundle works analog to the node flow bundle. It outputs paths which lead
via the marked main node(s). You have to select the demand segment, whose paths should be
taken into account for flow bundle calculation.
659 PTV AG
Link flow bundle (PrT and PuT)
The link flow bundle outputs all paths which lead to the marked link(s). You have to select those
demand segments both in PrT and PuT, whose paths should be taken into account for flow
bundle calculation. In PuT you also have the possibility of defining further filter criteria for PuT
network objects. These correspond to the criteria of the node flow bundle (see "Node flow
bundle (PrT and PuT)" on page 657).
Flow bundles based on stop points, stop areas and stops (PuT only)
The flow bundles for the three network objects of the stop hierarchy (stop point, stop area and
stop) output all paths which lead via each marked network object. For each of the three flow
bundles, as an additional filter criteria, you have to specify the passenger types to be taken into
consideration.
Boarding passengers (B): to display a flow bundle, the boarding line must correspond to the
selected entries (if for example only one stop was marked for the flow bundle, this means
that only those paths which start at the marked stop are output in the flow bundle).
Alighting passengers (A): the last line must correspond to the selected entries (if for
example only one stop was marked for the flow bundle, this means that only those paths
which end at the marked stop are output in the flow bundle)
Transfers (T): both lines must correspond to the selected entries (if for example only one
stop was marked for the flow bundle, this means that only those paths which intend to have
a transfer at the marked stop from one line to another, are output in the flow bundle). The
filter criteria for this type of transfer can be refined. You can, for example, specify that only
transfers from the transport system Bus to transport system Tram or from line 002 to line
001 should be taken into consideration.
Through passengers with stop (W): Through passengers are passengers which travel with
a line which travels via the stop, but do not get off there.
PassThroughNoStop (N): Through passengers without a halt at the stop are passengers
which travel with a line, which traverses via the stop, but which does not stop there.
Zone and main zone flow bundle (PrT and PuT)
Flow bundles for the network objects zone and main zone output all paths which lead via the
marked network object(s). You have to select those demand segments both in PrT and PuT,
whose paths should be taken into account for flow bundle calculation. For the flow bundle
definition you have to specify the desired traffic types (origin traffic, destination traffic or both
traffic types). Please note that zones cannot be traversed. They can only be picked as the first
(origin zone) or last search object (destination zone) of a path or as a zone with origin and
destination demand.
Origin traffic: all paths which start in the selected zone or main zone
Destination traffic: all paths which end in the selected zone or main zone
Both origin traffic and destination traffic: all paths which start or end in the selected zone
For PuT as for links and nodes you also have the possibility of defining further filter criteria for
PuT network objects. More information can be found with the description of the node flow
bundle (see "Node flow bundle (PrT and PuT)" on page 657).
660 PTV AG
11.1.2 Flow bundle definition through selection of traffic types
You can filter the paths of the flow bundle display by the traffic type (Internal traffic, Origin
traffic, Destination traffic, Through trips, External trips, or Bypassing internal trips) if you set
links or time profiles active or passive.
In the following example, Lynnwood town center through traffic is illustrated by the flow bundle
of traffic types. Only those paths are displayed in the flow bundle which start and also end at
an external zone. In the illustration 219, the flow bundle for the through traffic and also one for
the flow bundle paths of external zones 136 to 27 is displayed.
Illustration 219: Display of through traffic with a flow bundle of active links

For both network objects (time profiles and links) the traffic types internal traffic, origin traffic,
destination traffic, through traffic, external traffic and bypassing internal traffic are
distinguished. For links these have the following meanings:
Internal traffic: Paths which only use active network objects (links and time profiles) (to only
display the paths which lie within the urban area in the flow bundle display, for example)
Note: At least one link or one time profile needs to be passive in order to calculate a flow
bundle of transport systems. To set it passive use the filter (see User Manual, Chpt. 2.5,
page 124) or the spatial selection (see User Manual, Chpt. 2.6, page 144).
661 PTV AG
Origin traffic: Paths which start at an active network object (to display all commuter flows
from the urban area to the surrounding area as a flow bundle, for example)
Destination traffic: Paths which end at an active network object (to display all commuter
flows from the surrounding area to the urban area as a flow bundle, for example)
Through traffic: Paths which start and end with a passive object, in between however, uses
at least one active object (to display the HGV traffic which passes through a conurbation as
a flow bundle for example)
External traffic: Paths which do not use an active network object (to display the traffic which
drives around the conurbation as a flow bundle, for example)
Bypassing internal traffic: Paths which start and end with an active network object, in
between however, use at least one passive network object (to display the traffic for
example, which starts and ends in the urban area, but on its route traverses through the
surrounding area, because there is a by-pass which has advantages concerning the
speed)
For active time profile path filters it is considered, which of the path leg uses an active or
passive time profile (for each path leg there is a clear time profile which is used by the path leg,
hence, the filter settings have an effect for time profiles on the path leg). Table 266 shows what
relevance the traffic types have for the path filters for active time profiles.
The abbreviations in Table 266 have the following meaning:
a ... active time profile
p ... passive time profile
x ... irrelevant if active or passive time profile
Table 267 graphically shows the meaning of traffic types in path filters for active time profiles.
Number of path legs 1 2 3 4
Internal traffic a a-a a-a-a a-a-a-a
Origin traffic - a-p a-x-p a-x-x-p
Destination traffic - p-a p-x-a p-x-x-a
Through trips - - p-a-p p-a-x-p or
p-x-a-p
External trips p p-p p-p-p p-p-p-p
Bypassing internal trips - - a-p-a a-p-x-a or
a-x-p-a
Table 266: Traffic types against the status (active / passive) of the path legs
Internal traffic
Through trips
Origin traffic
Table 267: Meaning of traffic types in path filters for active time profiles
662 PTV AG
To demonstrate the application use, some example evaluations will be illustrated with path
filters via active time profiles.
1. Determine the number of passengers using long-distance trains on all path legs
All time profiles are active for long-distance lines, all others are passive
Selection of the traffic type internal traffic
2. Determine the number of passengers using a long-distance line on at least one path leg
All time profiles are active for long-distance trains, all others are passive
Selection of the traffic types internal traffic, origin traffic, destination traffic, through
traffic and bypassing internal traffic
3. Determine the number of passengers using at least one long-distance line on at least one
path leg and at least one public transport line on one path leg
All time profiles are active for long-distance trains, all others are passive
Selection of the traffic types origin traffic, destination traffic, through traffic and
bypassing internal traffic
11.1.3 Combination of flow bundle criteria
For the paths determined by a flow bundle, you can also combine several criteria and connect
them with AND THEN or OR. You can also combine PrT criteria and PuT criteria. The flow
bundles in show for example a combination of AND THEN terms and OR linksillustration 220.
All paths which start in zone 102 and end in zones 1, 2 or 5 are output in the flow bundle. For
zone 102 the traffic type origin traffic was permitted, for zones 1, 2 and 5 only traffic type
destination traffic. The required settings can be seen in the window, in illustration 220.
Destination traffic
Bypassing internal trips
External trips
Legend
Active time profile
Passive time profile
Table 267: Meaning of traffic types in path filters for active time profiles
663 PTV AG
Illustration 220: Paths which start in zone 102 and end in zones 1, 2 or 5
Definition of an AND THEN term
The flow bundle describes all paths from origin to destination which traverse all marked
network objects in exactly the order in which they succeed in the AND THEN term.
illustration 221 shows an AND THEN term which contains ten links. All paths which traverse
these links in the specified sequence are displayed.
664 PTV AG
Illustration 221: All paths which traverse a link section in north direction

Definition of an OR link
By inserting an OR link (see User Manual, Chpt. 11.1.3, page 1191), the AND THEN term is
completed. The flow bundle describes all paths, which fulfill at least one path filter criteria,
meaning one of the AND THEN terms linked with OR.
Any number of AND THEN terms can be combined by OR operations. Every path is only output
once with the flow bundle, even if it is found for several AND THEN terms.
illustration 222 shows how a PrT flow bundle and a PuT flow bundle can be illustrated
simultaneously with an OR link. The PrT flow bundle shows all PrT paths which traverse the
nodes 106062539 and 106062191. The PuT flow bundle shows all PuT paths which traverse
the stops 106061623 and 106063464.
Notes: Any number of nodes, main nodes, stops, stop areas, stop points and links can be
linked in any order.
Zones and main zones can only be the beginning or end of a path and can therefore not be
traversed.
665 PTV AG
Illustration 222: Combination of flow bundles for PrT and PuT by using an OR link
11.1.4 Flow bundles with alternative routes
If you want to display all paths in the flow bundles which do not traverse the selected network
objects, you have the possibility of displaying these alternative routes. Only those OD relations
are taken into consideration, which use the selected network objects. If 60% of the paths of an
OD pair run via the link for the selected link s, the alternative routes then make up the
remaining 40% of the paths of this relation. Those are the OD pair paths which are not
traversing via the selected link s. In the example in illustration 223, two links of a by-pass (in
both line directions) are marked for the flow bundle. The links of a direction are each combined
in an AND THEN term. Both AND THEN terms for both directions are linked via an OR link.
This means that all paths are displayed which lead across this link section, independent of the
direction.
666 PTV AG
Illustration 223: Link flow bundle with AND THEN term and OR link
In illustration 224 a flow bundle with the alternative routes is displayed. Those paths are output,
which do not lead across the marked link section, for all OD pairs, for which paths have been
found in the origin flow bundle. The comparison of the two illustrations shows, that most traffic
uses the by-pass on these OD pairs. Only a few road users choose the routes which lead
through the city. In a planning project the effectiveness of a created measurement could thus
be allocated.
667 PTV AG
Chapter 11.2: Isochrones
Illustration 224: Link flow bundle with alternative routes
11.2 Isochrones
Based on one or several selected network objects, isochrones visualize the accessibility of
other network objects. The accessibility can be classified in accessibility intervals. The
intervals can be displayed in the network editor with different colors. This is how you can
highlight all towns, for example, with the same color, which can be accessed from a specific
node in the same time. In practice, isochrones are used for example to analyze the catchment
area of stops. In illustration 225 all stop areas in the urban area are marked and then an
isochrone calculation is carried out. You can see, that especially potential PuT passengers
from the eastern part of the city (colored dark red) need more than 8min to the next stop.
668 PTV AG
Illustration 225: Isochrones to display the accessibility of stop areas
illustration 226 illustrates with a simple example the effectiveness of isochrones. In this
example, isochrones were drawn based on node 20. The travel time in the loaded network
(tCur) was used as a choice criterion. The links were labeled with these times. The link
segments were colored with different colors dependent on the accessibility (here depending on
tCur) (see User Manual, Chpt. 12.2.3.9, page 1274). If for example you travel from node 20 via
node 11 to node 41, the in-vehicle time is 29min 35s. According to this, the last link section is
colored dark red before node 41, because here your journey is longer than 26min.
669 PTV AG
Illustration 226: Functional principle of isochrones with a simple example
If several network objects are selected for the isochrone display, the shortest path from the
selected network objects to the link section is calculated, for each link section. The shortest of
these shortest paths then determines which accessibility interval is assigned to the link section.
If, for example, nodes 21 and 31 are selected for the isochrone display and a link section can
be reached from node 21 in 22min and from node 31 in 28min, the link section is assigned to
the accessibility interval <= 22min and colored accordingly.

11.2.1 PrT isochrones
There are two possibilities of displaying PrT isochrones in the network.
Display of the accessibility of link sections
Classified display of nodes or zones by the Isochrones Time PrT
The accessibility is determined via a shortest path search, where the following path search
criteria can be used.
tCur (travel time in loaded network)
t0 (travel time in unloaded network)
Distance
Impedance
AddValues 1 to 3

Note: The accessibility of network objects can be displayed simultaneously in the network for
both PuT and PrT.
Note: When selecting of the route choice criterion, note that t0, tCur and Impedance
correspond as long as no assignment has been calculated.
670 PTV AG
Accessibility of link sections
The link sections are drawn in the color of which accessibility interval they belong to.
illustration 227 shows the accessibility of link sections from marked node 7357. Dark red
colored link sections can only be reached in more than 10min.
Illustration 227: Accessibility of link sections from node 7357
Classified display of network objects
The classified display of the network objects nodes and zones is done with the output attribute
Isochrones Time PrT. This means, that nodes and zones are colored depending on their
Isochrones Time PrT. In illustration 228 a classification of the zones was made with the
Isochrones Time PrT.
671 PTV AG
Illustration 228: Zones classified according to their Isochrones time PrT
11.2.2 PuT isochrones
PuT isochrones visualize the accessibility of nodes, stops, stop areas, stop points, and zones.
The accessibility is determined on the basis of a timetable-based connection search. It is
possible to include only active vehicle journey sections in the search and to confine the
maximum number of transfers. Furthermore, you have to specify the time interval, in which
connections should be searched, and an extension for the timetable-based connection search.
The extension is the period after the specified time interval, where connections have to have
reached their destination. Nodes, zones or stop areas or a combination can be marked for
isochrones.
In PuT there are two possible ways of displaying isochrones.
Drawing the isochrones as 2D display
Both attributes Isochrones Time PuT and Isochrones Number of transfers PuT can be
drawn for the classification of the accessibility intervals.
Classified display of network objects node, zone, stop, stop area and stop point
Classification can be made with the attributes Isochrones Time PuT or Isochrones
Number of transfers PuT.
Isochrone display in 2D
For the 2D display, the network background is colored depending on the accessibility intervals.
The following attributes can be used, for the definition of the accessibility intervals.
Isochrones time PuT
PuT journey time from start (marked node, zone or stop area) to each network object for
which the Isochrones Time PuT was calculated (node, zone, stop, stop area or stop
point). This display form is used in illustration 229 to visualize the accessibility of stop
672 PTV AG
areas. The main station is marked, which means, that the isochrones reproduce the PuT
journey time from the main station.
Illustration 229: 2D display of the accessibility of stop areas from the main station
Isochrones Number of transfers PuT
Alternatively, the 2D display can also be classified according to the Isochrones Number
of transfers PuT.
Classified display of network objects
For PuT isochrones it is possible to display the nodes, zones, stops, stop areas and stop points
as classified. The following two attributes can be used.
Isochrones time PuT
PuT journey time from start (marked node, zone or stop area) to each network object,
calculated for the Isochrones time PuT (node, zone, stop, stop area or stop point).
illustration 230 shows an example, where the stops are displayed as classified. The stop
Karlsruhe main station is marked as start. The stops are illustrated as circles and their
coloring depends on the time in which each stop can be reached from the main station.
673 PTV AG
Illustration 230: Classified display of stops on the basis of the isochrone time PuT
Isochrones Number of transfers PuT
Number of transfers from the start (marked node, zone or stop area) to each network object
for which the PuT isochrone was calculated (node, zone, stop, stop area or stop point).
illustration 231 shows the same example as illustration 230. As a classification criteria the
Isochrones Number of transfers PuT was selected here. It is therefore apparent which
stops can be reached from the main station with none, one or more than one transfer.
674 PTV AG
Illustration 231: Classified display of stops on the basis of the isochrone number of transfers
11.2.3 Combination of PrT and PuT isochrones
VISUM allows you to simultaneously display isochrones for PrT and PuT in one network. This
is how the accessibility in PrT and PuT can be compared for example. In the example in
illustration 232 the stops are displayed as classified according to the Isochrones Time PuT.
The stop area 106062191 was marked for isochrone calculation. The link sections are
classified on the basis of the isochrone time PrT, for the PrT. Node 106062191 was marked as
a start object for the PrT isochrone, which is located where the corresponding stop area is. If
you compare the accessibility to the main station (stop area 106062529) from the marked node
or the stop area, it can be specified which temporal advantage it has driving the car or taking
the bus. Based on this comparison the appropriate measures can then be taken, for example,
what needs to be done to make PuT more attractive. illustration 232 graphically displays, that
the main station can be reached with PuT (106062529) in <= 6min from start (106062191). A
comparison with PrT (colored link sections) shows, that the same start-destination relation can
be covered in less than 3min.
675 PTV AG
Illustration 232: Comparison of the accessibility in PrT and PuT in graphical display
The exact numbers are delivered by the list view (see illustration 233). The exact Isochrones
Time PrT is 2min 50s, the Isochrones Time PuT is 5min 25s.
Illustration 233: Comparison of the accessibility in PrT and PuT in the list view
676 PTV AG
11.3 Shortest path search
With the shortest path search command you can determine the best paths from a chosen origin
to a chosen destination and display the result in the network (see illustration 234). Different
search criteria can be used to find the shortest path. The paths found can then be displayed in
a shortest path search list.
Illustration 234: Shortest path search between two nodes in PrT
An interactive shortest path search can be used especially to find errors in network modeling.
With the graphic output of the shortest path, you can quickly determine implausible shortest
paths in the network editor. It could thus occur, that links for a transport system were
mistakenly blocked by the modeler and therefore an unexpected path between two nodes is
assumed as the shortest path. With the shortest path search you can find such paths and undo
the road closure if necessary.
Shortest path search PrT
In PrT, shortest paths can be searched for between nodes, main nodes or zones. The shortest
path is searched for the selected traffic system respectively. The following choice criteria are
possible as search criteria.
677 PTV AG
Chapter 11.3: Shortest path search
t0 (travel time in unloaded network)
tCur (travel time in loaded network)
Impedance
Distance
AddValues 1 to 3 (this also allows the use of values of any other attributes as a criteria for
the shortest path search)
Shortest path search PuT
Shortest path search for PuT can either be done on the basis of the timetable (PuT tab) or
transport system-based (PuT TSys).
If it is carried out as timetable-based, the connection with a minimum search impedance
applies as the shortest path. Search impedance is thus any linear combination of journey time
and the number of transfers.
Search impedance = x journey time + y number of transfers
You can also specify, whether a shorter journey time or less transfers is more favorable for the
shortest path search. You can search for a timetable-based shortest path between two zones
or two stop areas.
The transport system-based shortest path search does not differentiate between individual
PuT lines. Modeling the transport supply only considers the links of a basic network with their
specific run times. The basic network can comprehend the following three possibilities:
All road and rail links of the link network
Only those links which are traversed by PuT lines
Only those links which are traversed by active PuT lines
From the links of this basic network a graph is constructed which forms the basis for a shortest
path search. Because individual lines are not distinguished, transfer stops with their respective
transfer times cannot be included in the search. It is possible, however, to include transfer
times between different transport systems (transfer penalties for transport system transfers,
such as between bus and train). The transport system-based shortest path search can be
executed between two zones or two nodes.
678 PTV AG
679 PTV AG
12 Tabular and graphic display
VISUM provides a wide range of graphical and tabular display options for the data of your
traffic model. You can analyze the model data from different views. It is possible to output the
link volumes calculated in an assignment as a table in a list and graphically as link bars in the
network editor (see "Graphical and tabular display of link volumes" on page 679). Below,
display types which are often used are introduced in examples. Primarily, these are there to
give an idea on the diversity of the graphic display possibilities in VISUM. You can find all
setting possibilities for graphic parameters and lists in the detailed description (see User
Manual, Chpt. 12, page 1227).
Illustration 235: Graphical and tabular display of link volumes
Subjects
Lists
680 PTV AG
Chapter 12: Tabular and graphic display
Bars
Categorized display with attribute values
Labeling with tables
Labeling with diagrams
Turn volumes
Desire lines
Stop catchment areas
Lane allocation
2D display
Timetable network graph
Column charts
Evaluations in the timetable editor
12.1 Lists
Use lists for the following applications:
To get an overview of the network object data of your model and network analyses results
in table form
To save attribute files for the exchange with other VISUM models
To export any attribute of the list in a database or in a spreadsheet
To simultaneously change the attribute values of multiple network objects, as efficiently as
in spreadsheets
To display the set of network objects, which correspond to the set filter criteria
The list columns contain freely selectable attributes, the rows contain different objects. In
addition to the direct network object attributes, you also have access to indirect attributes in
lists, therefore attributes of other network objects, for example in the zone list to the number of
origin connectors (see User Manual, Chpt. 2.2, page 98).
You can specify which attributes should be displayed in the table columns, in all lists. The
selection of displayed attributes together with the format of the table columns (e.g. decimal
places, alignment) is called list layout (see User Manual, Chpt. 12.1, page 1227). There are
two types of lists, specific lists for each network object type and evaluation lists.
12.1.1 Specific network object lists
Specific lists are provided for all network object types (see "Example for link lists" on
page 681). Here you can edit the input attributes of the network objects and display additional
non-editable attributes, such as assignment results for example (see "Example for link lists" on
page 681). Some of these lists have special features that are explained below.
681 PTV AG
Chapter 12.1: Lists
Illustration 236: Example for link lists
Territory lists
Both territory lists contain PrT and PuT indicators precisely broken down. This is how the
indicators can be calculated based on spatial territories, for example the service kilometers
which lie within a county (see "Spatial cut (Territory cut)" on page 608). The sublists Basis and
PuT detail are available for territories.
Basis The list outputs precise indicators of PrT and PuT for each territory. Dependent on the
indicator, an assignment or the procedure territory indicators or PuT operating indicators have
to be calculated before.
Tip
To get more detailed information on how to calculate the values for this list, have a look at the
files IndicatorOrigin.xls and IndicatorAvailability.xls in your Doc directory of your VISUM
installation.
Table 268: Territory lists
682 PTV AG
OD pair lists
In an OD pair list you can output the following attributes for each relation between two zones:
Values from the skim matrices of the model
Values from the demand matrices of the model
Direct distance between zones
Values from the direct and indirect attributes of the From zone or To zone of the relation

Stop lists
VISUM provides lists for the network object stop, stop area and stop point. In addition to the
base list for the network objects themselves, you can also find a list for the timetables at stop
points and the transfer times between the stop areas of the stops, the transport systems, and
the time profiles.
PuT
detail
For PuT, the indicators for each territory can be refined on the following levels of the line
hierarchy, and if desired also per vehicle combination (see "Spatial cut (Territory cut)" on
page 608).
Territory x Transport system
Territory x Main line
Territory x Line
Territory x Line route
Territory x Time profile
Territory x Vehicle journey
Territory x TSys x Vehicle combination
Territory x Main line x Vehicle combination
Territory x Line x Vehicle combination
Territory x Line route x Vehicle combination
Territory x Time profile x Vehicle combination
Territory x Vehicle journey x Vehicle combination
This is how you can evaluate service kilometers per line within a territory for example.
Note
The list only contains entries after the procedure PuT operating indicators has been
calculated.
Note: The matrix values can also be edited in this list, so that you do not have to switch to the
matrix editor.
Stop points
arrivals/departures
The list exports the trips and attributes of any stop point selected by the user such
as, Arrival and Departure. As an option, you can also filter according to time
profiles at the selected stop point.
Stop areas:
Transition walk
times
For each stop, the list contains the transfer times between the stop areas of the
stop. Use the list for example, if you want to change the transfer times of multiple
stops. You therefore do not have to open the window Edit stop for each individual
stop, to change the times.
Table 269: Stop lists
Table 268: Territory lists
683 PTV AG
Chapter 12.1: Lists
Item lists
In addition to basis lists (for example line route list) for the network objects of the line hierarchy
and for system routes, item lists are also offered (for example the line route items list). These
lists contain the individual elements (items) of the network object. These are:
Line lists
In addition to the base list for network objects of the line hierarchy and the respective course
lists, VISUM offers two special lists for coupling.
Block lists
To display and edit input and output attributes of line blocking, the lists block versions, blocks
and block items are available.
Time profiles:
Transition walk
times
For each stop, the list contains the transfer times between the time profiles of the
stop.
Transport systems:
Transition walk
times
For each stop, the list contains the transfer times between the transport systems of
the stop.
Line route items All nodes and stop points of the line route
Time profile items All profile points of a time profile (see User Manual, Chpt. 2.30.3.3, page 393)
Vehicle journey items All profile points of the time profile which are traversed by the trip selected by
the user
System route items All nodes and stop points which lie on the system route
Table 270: Item lists
Coupling sections All coupling sections with their From stop point No and To stop point No. This
is how you can illustrate which stop points are coupled between which time
profiles.
Coupling section items The list shows which time profile is coupled between which time profile
elements.
Table 271: Line lists
PuT Line block
versions
Shows the block versions contained in the model.
Blocks The list shows the blocks of all block versions. As an option, only the blocks of a
block version selected by the user can be displayed.
Block items The individual elements of all blocks are contained in this list. The list shows the
parts which make up a block and in which order these are traversed (service trips,
empty trips, stand times, but also user-defined block item types). As an option, only
the items of a block version selected by the user can be displayed.
Table 272: Block lists
Table 269: Stop lists
684 PTV AG
12.1.2 Matrix list
The matrix list shows an overview of all matrices (see User Manual, Chpt. 12.1.9, page 1249).
12.1.3 Evaluation lists
Evaluation lists only contain results from calculations or statistical values on the network
model. Their entries can therefore not be edited. An example is the PrT path list:
Illustration 237: PrT path list
Evaluation lists for paths
The paths found between origin and destination zone in the assignment, are output in the path
lists (see User Manual, Chpt. 12.1.8, page 1244).

Note: The lists are empty if no assignment was calculated.
PrT paths Lists the paths calculated in a PrT assignment for the selected demand
segment. The rows contain the paths from one origin zone to a destination
zone.
PrT path sets Displays any existing PrT path sets.
PrT paths on link level Compared to the PrT path list, the links which lie on the path are listed
additionally for each path. This is how the exact course of the path can be
comprehended.
OD pairs PuT Lists aggregated skims for each OD pair, which were calculated for the
routes or connections found with the assignment.
Note
You must calculate the skims beforehand for PuT with the assignment or
in a separate procedure (see "PuT skims" on page 414), for PrT via the
procedure Calculate skim matrix (see "PrT skims" on page 271).
PuT paths Lists the paths calculated in a PuT assignment for the selected demand
segment. The rows contain the paths from an origin zone to a destination
zone.
Table 273: Evaluation lists for paths
685 PTV AG
Chapter 12.1: Lists
Evaluation lists for transfers
There are two different transfer lists, in which you can display the transfers for each stop or
time profile/transport system (see User Manual, Chpt. 12.1, page 1227).

Evaluation lists for paths from the shortest path search
The shortest path list outputs the attributes of a previously calculated shortest path search for
PrT or PuT.

Statistical evaluation lists
PuT path legs Lists all path legs (see "Network model" on page 17) of each route or
connection of an OD pair from an origin zone to a destination zone for the
selected demand segment, found by the PuT assignment.
Note: The lists do not contain any entries if no PuT assignment was calculated beforehand.
Note: A previously calculated assignment is not required.
Statistics - Network
information
The list provides statistical information on the current network.
Network
Number of objects per network type
License
Maximum number of objects for the current VISUM license
Max
Maximum number of objects for the largest VISUM license
Furthermore, the list also provides detailed information (with subattribute)
on the specific number of network objects. These are for example
Number of origin connectors or destination connectors of PrT or PuT
Number of one-way roads or turning prohibitions for each transport
system
Statistics Goodness of
PrT assignment
Output of convergence criteria as indicators of the PrT assignment quality
(see "Convergence criteria of the assignment quality" on page 288).
Note
The convergence criteria are automatically calculated for the PrT
assignment procedures Equilibrium, Equilibrium_Lohse and Stochastic
assignment.
Statistics - Goodness of
PrT assignment with ICA
Output of convergence criteria as indicators of the PrT assignment quality
for assignments with ICA
Statistics - Assignment
analysis
Output of the statistical evaluation of the assignment analysis for PrT or PuT
(see "Assignment analysis PrT" on page 403 and "Assignment analysis
PuT" on page 475)
Statistics PuT
assignment statistics
Output of indicators for PuT assignments which refer to the entire network
Note
The indicators are calculated automatically with a PuT assignment (see
"Transport system-based assignment" on page 428).
Table 274: Statistical evaluation lists
Table 273: Evaluation lists for paths
686 PTV AG
12.2 Bars
You can draw links and connectors, whose width complies with the values of an indirect or
direct attribute of the link or the connector (see User Manual, Chpt. 12.2.4.10, page 1289). The
link volume from a PrT assignment can thus for example be visualized, like in illustration 238,
by scaling the link bar with the attribute Volume [Veh] PrT.

Illustration 238: Link bars with PrT volume
Connector bars can also be drawn. In illustration 239 the attribute Volume [Veh] PrT is
displayed on the connectors.
Emissions (HBEFA) Output of the skims calculated network-wide by the emission calculation
according to HBEFA (see "Emission calculation according to HBEFA 3.1" on
page 618)
Table 274: Statistical evaluation lists
687 PTV AG
Chapter 12.2: Bars
.
Illustration 239: Connector bars with PrT volume
You can draw as many bars as you like with different attributes along the link or connector. This
is how you can simultaneously display the volume from a PrT assignment (attribute Volume
[Veh] PrT) and the volume from a PuT assignment (attribute Volume [Pass] PuT) on a link,
as can be seen in illustration 240.
688 PTV AG
Illustration 240: Two link bars with PrT and PuT volume
12.3 Categorized display with attribute values
The display of the active network objects in the network editor can be categorized with attribute
values of the network object (see User Manual, Chpt. 12.2.8, page 1315). This makes it
possible to draw links differently in dependency of their link type, for example. In
illustration 241, illustration 242 and illustration 243 link and zone categorizations are
illustrated.
689 PTV AG
Chapter 12.3: Categorized display with attribute values
Illustration 241: Categorized link display according to link category
690 PTV AG
Illustration 242: Categorized link display according to saturation PrT
691 PTV AG
Chapter 12.3: Categorized display with attribute values
Illustration 243: Zone categorization according to origin traffic
Bars (see "Statistical evaluation lists" on page 685) can also be displayed in categories. In
dependency of attribute Saturation PrT, the link bar is colored red, green or yellow in
illustration 244.
692 PTV AG
Illustration 244: Link bar display categorized according to saturation PrT
12.4 Labeling with tables
In the network editor, the network objects can be labeled with freely configurable tables. You
can output up to 5 rows and 2 columns of attribute names and the respective values, but also
free text, in the table (see User Manual, Chpt. 12.2, page 1253). This is how you can label the
stop points in your model with tables for example, which show the number of boarding
passengers, transfers and alighting passengers (illustration 245).
693 PTV AG
Chapter 12.5: Labeling with diagrams
Illustration 245: Table display of boarding passengers, transfers and alighting passengers at stops
12.5 Labeling with diagrams
In the network editor, the network objects can be labeled with freely configurable charts (see
User Manual, Chpt. 12.2.3.5, page 1267). Bar and pie charts are available. For zones you can
display the number of inhabitants and jobs in a column chart for example (illustration 246).
694 PTV AG
Illustration 246: Number of residents and workplaces per zone
You can also display the results of the mode choice (see "Mode choice" on page 113) the
distribution of travel demand to the individual transport modes for each zone in a pie chart
(illustration 247).
695 PTV AG
Chapter 12.6: Turn volumes
Illustration 247: Display of the mode selection as pie charts for zones
12.6 Turn volumes
Turn volumes visualize attributes of turns (see "Network model" on page 17) at individual
nodes (see User Manual, Chpt. 12.5, page 1336). If you select the attribute Volume [Veh] PrT
(AP) for example, after an assignment you can illustrate which traffic volumes apply to the
turns of a node (illustration 248).
The turn attributes can also be displayed in a turn list (see "Lists" on page 680).

Tip: In the junction editor, you can also display turn volumes (see User Manual, Chpt.
2.39.18, page 542).
696 PTV AG
Illustration 248: Turn volume with display of turn volumes
12.7 Desire lines
A desire line visualizes the values for relations between zones (From zone to To zone). The
values displayed on the desire line may derive from different origins.
From a demand matrix (for example to visualize the demand between zones)
From a skim matrix (for example to visualize the journey time between zones)
As a value from the network model itself (for example the direct distance between zones)
From a zone attribute of the From zone or the To zone of the relation (for example to
illustrate the From zone\origin traffic to other zones)
You can draw a desire line link (direct distance between the centroid of the zones) or a desire
line bar for the proportional display of values, for each relation (see User Manual, Chpt. 12.4,
page 1326).
The display of desire lines is useful for illustrating demand matrices and indicator matrices in
the network editor. This is how you can get an overview, which OD pairs (From zone to To
zone) are especially in demand, for example. The example shown in illustration 249 shows the
travel demand between the zone Oppidum and all other zones. It is clear, that there is an
especially high demand between the zones Oppidum and B town.
697 PTV AG
Chapter 12.7: Desire lines
Illustration 249: Desire line with bars scaled at the demand between zones
The desire line is drawn on the direct distance between the zone centroids. If you are
interested in the exact course of the paths between origin and destination zones, then use the
Shortest Path Search (see User Manual, Chpt. 11.3, page 1208).
Combined with the OD pair filter (see User Manual, Chpt. 2.5.6, page 139) the display of the
desire lines on OD pairs, which correspond to the filter criteria, can be confined. As an
alternative, the number of the OD pairs displayed can also be displayed via a classified display
Furthermore, the desire line can also be drawn classified. As shown in illustration 250, you can
highlight OD pairs with a high traffic demand with colors, for example.
698 PTV AG
Illustration 250: Desire line with bars classified according to the demand between zones
12.8 Stop catchment areas
Using stop catchment areas, you can draw circles around the stops, to graphically display the
PuT development quality in the network. The circle can either be drawn with a constant radius
or in proportion to the values of direct or indirect stop attributes. Circles were drawn with a
constant radius of 400m in the example in illustration 251. As you can see, the Eastern part of
the small town is insufficiently accessible by PuT, so that the extension measures should aim
towards making this territory more accessible.
699 PTV AG
Chapter 12.8: Stop catchment areas
Illustration 251: Stop catchment areas with a large radius of 400m
Stop catchment areas can also be drawn classified. In illustration 252 catchment areas with a
radius of 300m are drawn around the stops. The circles of stops with more than 1000
departures per analysis period are red, stops with less than 500 departures, orange and stops
with less than 100 departures, green. This is how you can display how strongly stops are
frequented and how the entire network is made accessible by PuT, in a graphic.
700 PTV AG
Illustration 252: Stop catchment areas classified according to the number of departures
12.9 Lane allocation
To visualize the node topology in the network editor (see "Junction modeling" on page 66) you
can graphically display the lane allocation at nodes. A rectangle is then drawn for each
outgoing link of a node, which is open for one or more PrT transport systems and which has
one or more lanes. Inside the rectangle, an arrow is drawn for each approach lane and an
arrow head for each permitted lane turn. illustration 253 shows an example of a node with four
legs.
701 PTV AG
Chapter 12.9: Lane allocation
Illustration 253: Lane allocation in the network display
A classified display is also possible for the lane allocations, by direct and indirect node
attributes. This is how you can export the lane allocation in different colors, depending on the
node volume. illustration 254 illustrates this with an example of a roundabout.
Illustration 254: Classified lane allocation according to the node volume
702 PTV AG
12.10 2D display
For point objects, (for example nodes or stops) the two-dimensional (extrapolated) display type
can be actuated for display of the distribution of attribute values. Any numerical attribute can
be selected for display of extrapolated attribute values.
The attribute value of the point object is extrapolated over the entire network area. For two-
dimensional visualization, up to 10 value ranges can be defined with a specific background
color assigned to each interval.
The extrapolation process
Based on each VISUM object of the selected point object class (nodes, zones, ...) an
extrapolated value is computed for each pair of co-ordinates in the network area. In this
process, the extrapolated value rises linearly with growing distance from the point object.
The rising speed is specified as parameter V-access.
The final extrapolated attribute value of a pair of co-ordinates is the minimum of all attribute
values calculated from all VISUM objects.
Example
Node P
1
with co-ordinates (x,y) = (0,0) has AddVal1 = 100. Point P = (300, 400) has a distance
of to P
1
. This distance is 500m if the network scale is 1. Using V-access
= 5 (km/h), the AddValue will rise by 360, because for 500 m exactly 360 seconds are required
if speed = 5 km/h. The P
1
-related extrapolated AddValue of point P sums up to 100 + 360 =
460.
Finally, the minimum of all extrapolated values calculated by VISUM from all point objects P
i
of
the network is the extrapolated AddVal attribute value of point P.
Based on user-defined classification intervals, the graphical display of attribute value
distribution will show rings of value ranges having specific colors around any point object
(illustration 255) of the selected class.
500 400
2
300
2
+ =
703 PTV AG
Chapter 12.10: 2D display
Illustration 255: Isochrone view
Originally, this display type has been implemented in VISUM for graphical display of
isochrones (see "Displaying isochrones and the accessibility of network objects" on
page 1197) showing accessibility of network objects.
For the extrapolation of numerical attributes of VISUM point objects, the input parameters do
not necessarily have to be of the speed or time data type.
V-access (access speed) for extrapolation of attribute values
tMax-access (maximum extrapolated attribute value) for classified display
V-access (access speed)
Internally, the formula is still used by VISUM. For calculation of t values, speed is
specified by the user as parameter v = v - access and distance s results from the network scale.
For attributes of other data types (for example AddValues without [unit]) the following has to be
taken into account: Formula produces a value in [seconds], which is, depending on the
attributes data type, interpreted as 1 unit. See example above: the resulting 360 [s] are added
to the AddVal data.
v
s
t
-- =
t
s
v
-- =
704 PTV AG
12.11 Timetable network graph
With the timetable network graph you can illustrate the following:
Line route items in a PuT network with headway
Connections at stops
Service trip patterns in the network (see "Calculating Service trip patterns" on page 1016)
The schematized view which could only be achieved with a third-party program called VIRIATO
(SMA + Partner, Zurich) so far, visualizes the systematic of a PuT network that includes, for
example, service frequencies, depots and transitions.
Service trip patterns as well as departure and arrival minutes are visible at a glance at central
points in the PuT network so that transfer waiting times are clearly evident and departures can
be shifted. Optionally, transfers can be displayed as connecting lines within a node.
VISUM automatically generates the layout of the display. It can, however, also be edited
manually. The illustration 256 shows the network display for the example Example.ver and the
illustration 257 the fixed time plans for the same network. illustration 258 shows the timetable
network graph created on this basis.
Illustration 256: Stops in the network display
705 PTV AG
Chapter 12.11: Timetable network graph
Illustration 257: Regular services mode in the timetable editor
For a basic headway of one hour, the above network / timetable settings produce the following
timetable network graph (1st service pattern directed).
Illustration 258: Timetable network graph
706 PTV AG

12.12 Column charts
You can create column charts with values of direct and indirect attributes (see "Attributes" on
page 80) from the network editor, for individual network objects (see User Manual, Chpt. 12.12,
page 706). You can create common chart displays directly from VISUM, without having to
export list contents to Excel, to create the graphics there.
There are two standard types of column charts:
Column charts for time intervals: If you have defined time intervals (see "Spatial and
temporal correlations in VISUM" on page 71) in your model, you can display an attribute for
each time interval, for a network object. This function especially supports you when
analyzing dynamic assignments. illustration 259 shows a column chart, for which three
columns with the passenger volume for the entire PuT, the tram and the bus are drawn for
a link, for each time interval.
Illustration 259: Column charts for time intervals
Column charts for relations between network objects. For a network object (for example
stop), you can display attributes, linked via the VISUM data model network object (for
example the stop points of a stop) as column charts. In illustration 260, a column chart was
invoked for the stop Durlacher Tor and a column was drawn for each network object stop
point. As you can see, the stops are assigned three stop points, for which each the number
of boarding passengers, alighting passengers and transfers is displayed as a column chart.
Note: An entry of 1 to 2 hours is recommended for the base headway. For a base headway
of 1h, a headway of 20 minutes would result in a drawn line with three departure times (for
example 09, 29, 49).
707 PTV AG
Chapter 12.13: Evaluations in the timetable editor
Illustration 260: Column chart for relations between network objects
12.13 Evaluations in the timetable editor
In the VISUM timetable editor you are provided with the tabular timetable as a tabular and the
graphical timetable as a graphical evaluation tool (see User Manual, Chpt. 2.42, page 563).
The Timetable editor also offers a block view for line blocks (see "Display of line blocks in the
block view" on page 1043).
Tabular timetable
In the standard view, the tabular timetable is presented as in illustration 261.
708 PTV AG
Illustration 261: Tabular timetable in the standard view
In the regular service mode (see User Manual, Chpt. 2.42.4, page 567) all trips are displayed
as regular trips with the additional attributes Headway start, Headway end, Headway time
and Number of vehicle journeys (illustration 262).
709 PTV AG
Illustration 262: Tabular timetable in regular service mode
You can also display the columns of the tabular timetable as classified (see User Manual, Chpt.
12.2, page 1253). In the following example, the table background is classified by revenues
(illustration 263).
710 PTV AG
Illustration 263: Table background classified by revenue
Graphical timetable
Trips and trip sections are displayed graphically in the graphical timetable. In illustration 264,
the stroke display is classified according to lines (see User Manual, Chpt. 12.2, page 1253), to
distinguish trips of different lines by using different colors.
711 PTV AG
Illustration 264: Graphical timetable with classified display of trip line style properties
Item bars, which can be scaled with direct and indirect trip or trip section attributes, can be
drawn for trips and trip sections (see User Manual, Chpt. 12.2, page 1253). In the following
example, the Volume of the trips is used as scaling attribute (illustration 265).
712 PTV AG
Illustration 265: Item bars for trips
Item bars can also be classified (see User Manual, Chpt. 12.2, page 1253). In illustration 266
classification is carried out with the trip volume.
713 PTV AG
Illustration 266: Classification of item bars with the trip volume
VISUM offers the possibility of displaying multiple bars with different attributes on trips or trip
sections (see User Manual, Chpt. 12.2, page 1253). illustration 267 displays bars for
Boarding passengers, Alighting passengers and Through passengers.
714 PTV AG
Illustration 267: Display of item bars for boarding passengers, through passengers and alighting
passengers
715 PTV AG
Literature
Bellei, G.; Gentile, G.; Meschini, L.; Papola, N.: A demand model with departure time choice for within-
day dynamic traffic assignment.In: European Journal of Operational Research 175 (2006), No.
3, pages 1557-1576 (available online at URL http://www.sciencedirect.com)
Bellei, G.; Gentile, G.; Papola, N.: A within-day dynamic traffic assignment model for urban road
networks. In: Transportation Research B 39 (2005), No. 1, pages 1-29 (available online at URL
http://www.sciencedirect.com)
Bregman, L.M.: Ein Beweis der Konvergenz des Verfahrens von G.W.Sheleikhovski fr ein
Transportproblem mit Beschrnkungen (in Russisch). Shurnal vycisl.mat.i mat.fiz.7 (1967),
No.1, pages 147-156 (Convergence of the procedure)
Bregman, L.M.: Eine Relaxationsmethode zur Bestimmung des gemeinsamen Punktes konvexer Mengen
und ihre Anwendung zur Lsung konvexer Optimierungsaufgaben (in Russisch). Shurnal
vycisl.mat.i mat.fiz.7 (1967), Nr.3, page620-631 [Engl. translation: The relaxation method of
finding the common point of convex sets and its application to the solution of problems in
convex programming.U.S.S.R.Computational Math.Math.Phys. 7 (1967), pp.200-217]
Brilon, W.: Traffic engineering and the new German highway capacity manual.In: Transportation Research
A 28 (1994), No. 6, page 473 (available online at URL http://www.sciencedirect.com)
Brilon, W.; Weinert, A.: Bemessungsverfahren fr Knotenpunkte mit abknickender Vorfahrt. In:
Straenverkehrstechnik 7, 2002, pages 346-356.
Bundesministerium fr Verkehr (Hrsg.): Richtlinien fr den Lrmschutz an Straen, Ausgabe 1990
(RLS-90). Federal Ministry of Transport, Building and Urban Affairs, 1990
EMNID-Institut GmbH (Hrsg.): KONTIV 89: Bericht zur Methode. Anlagenband und Tabellenteil.Bielefeld,
1991 (Method report)
Evans, A.W.: Some properties of trip distribution methods. In: Transportation Research 4 (1970), No.1,
pages 19-36 (available online at URL http://www.sciencedirect.com)
Evans, S.P.; Kirby, H.R.: A three-dimensional Furness procedure for calibrating gravity models. In:
Transportation Research 8 (1974), No.2, pages105-122 (available online at URL http://
www.sciencedirect.com)
Frschner, G.: Verkehrsplanerische Berechnungsmethode des Straengterverkehrs. In: Wissenschaft
und Technik im Straenwesen, Heft 20, Berlin, 1982 (Transportation planning calculation
method)
Forschungsgesellschaft fr Straen- und Verkehrswesen (Hrsg.): Leitfaden fr Verkehrsplanungen.
Kln : FGSV, 1985. (Road Traffic Resarch Association in Germany), 1985
Forschungsgesellschaft fr Straen- und Verkehrswesen (Hrsg.): Richtlinien fr die Anlage von
Straen, Teil: Wirtschaftlichkeitsuntersuchungen (RAS-W86). Kln : FGSV, 1986 (Road
Traffic Resarch Association in Germany)
Forschungsgesellschaft fr Straen- und Verkehrswesen (Hrsg.): Empfehlungen fr
Wirtschaftlichkeitsuntersuchungen an Straen (EWS-97): Aktualisierung der RAS-W86.Kln :
716 PTV AG
Literature
FGSV, 1997. (Road Traffic Resarch Association in Germany)
Furness, K.P.: Trip forecasting. Unverffentlichter Vortrag. London, 1962
Furness, K.P.: Time function iteration. In: Traffic Engin. Control 7 (1965), No.7, pages 458-460
Gentile G.: Linear User Cost Equilibrium: a new algorithm for traffic assignment. Submitted for publication
, 2009
Gentile, G.; Meschini, L.; Papola, N.: Macroscopic arc performance models with capacity constraints for
within-day dynamic traffic assignment. In: Transportation Research B 39 (2005), No.4, pages
319-338 (available online at URL http://www.sciencedirect.com)
Gentile, G.; Meschini, L.: Fast heuristics for the continuous dynamic shortest path problem in traffic
assignment. Submitted to the AIRO Winter Conference 2005 special issue of the European
Journal of Operational Research on Network Flows, 2006
Gentile, G.; Meschini, L.; Papola, N.: Spillback congestion in dynamic traffic assignment: a macroscopic
flow model with time-varying bottlenecks. In: Transportation Research B 41 (2007), No.10,
pages 1114-1138 (available online at URL http://www.sciencedirect.com)
The Highways Agency (Hrsg.): The geometric design of roundabouts. In: Design Manual for Roads and
Bridges, Vol.6, Section 2, Part 3, TD 16/93.London, 1993
Kimber, R.M.: The traffic capacity of roundabouts. In: Transportation and Road research Laboratory report
LR 942.Crowthorne: Transportation and Road research Laboratory, 1980
Kimber, R.M.; Daly, P.N.: Time-dependent queueing at road junctions: Observation and prediction.In:
Transportation Research B 20 (1986), No.3, pages 187-203 (available online at URL http://
www.sciencedirect.com)
Kimber, R.M.; Hollis, E.M.: Traffic queues and delays at road junctions. Transportation and Road
research Laboratory report LR 909.Crowthorne: Transportation and Road research
Laboratory, 1979
Kirby, H.R.: Theoretical requirements for calibrating gravity models. In: Transportation Research 8 (1974),
No.2, pages 97-104 (available online at URL http://www.sciencedirect.com)
Kirchhoff, P.: Verkehrsverteilung mit Hilfe eines Systems bilinearer Gleichungen: Ein Beitrag zur
Entwicklung von Verkehrsverteilungsmodellen.Braunschweig, Technische Universitt, Institut
fr Verkehr und Stadtbauwesen, Diss., 1970 (Dissertation on Trip distribution)
Kirchhoff, P.; Leutzbach, W.; Pampel, E.; Holz, S.; Mott, P.; Sahling, B.M.: Verkehrs- und
Betriebsplanung. Forschung Stadtverkehr, Reihe Auswertungen, Heft A3, 1987. (Traffic and
Operational Planning)
Lamond, B.; Stewart, N.F.: Bregmans balancing method.In: Transportation Research B 15 (1984), No.4,
pages 239-248, (available online at URL http://www.sciencedirect.com)
Lebeuf, R.; Jrnsten, K.; Stewart, N.F.: On the use of Bregmans balancing method for the solution of
relaxed distribution problems. Tech.Rep. No.Montral, Universit de Montral, Dpartement
d'informatique et de recherche oprationelle (IRO), 1980
Leutzbach, W.; Haupt, T.; Mott, P.: Ermittlung der Verkehrsnachfrage. Forschung Stadtverkehr, Reihe
Auswertungen, Heft A4, 1988. (Determination of Travel Demand)
717 PTV AG
Literature
Lohse, D.: Berechnung von Personenverkehrsstrmen. In: Wissenschaft und Technik im Straenwesen,
Heft 17, 1977 (Calculating passenger demand flows)
Lohse, D.; Teichert, H.; Dugge, B.; Bachner, G.: Ermittlung von Verkehrsstrmen mit n-linearen
Gleichungssystemen Verkehrsnachfragemodellierung.Scientific series of Institut fr
Verkehrsplanung und Straenverkehr of TU Dresden, Vol. 5, 1997102, 1997 (Calculating
passenger demand flows)
Lohse, D.; Wegener, B.: Abschnitt 3: Verkehrsplanerische Berechnungsverfahren.In: Bauakademie der
DDR (Hrsg.): Richtlinie fr Stadtstraen. Teil I: Methoden und Verfahren der stdtischen
Verkehrsplanung, Ausgabe 1981. Berlin : Bauinformation, 1982 (Transportation planning
calculation procedures)
Mcke, P.A.: Ruske, W.: Straenverkehrstechnische Untersuchungen fr den zweiten Ausbauplan. In;
Strae und Autobahn 19 (1968), No.6, pages 201-211 (Transportation planning analyses)
Mhring, R.; Nkel, K.; Wnsch, G.: A model and fast optimization method for signal coordination in a
network. In: van Zuylen, H.; Middelham, F.(Hrsg.): Proceedings of the 11th Symposium on
Control in Transportation Systems - CTS 2006, pages 73-78, Delft, 2006
Nordic Council of Ministers (Hrsg.): Road Traffic Noise: Nordic Prediction Method. Tema Nord
1996:525. Denmark : Nordic Council of Ministers, 1996. ISBN 9291208361
Norm DIN 18005 Teil 2 September 1991. Schallschutz im Stdtebau: Lrmkarten; Kartenmige
Darstellung von Schallimmissionen. Berlin : Beuth Verlag, 1991 (Noise Prevention in Urban
Development)
Ortzar, J.D.; Willumsen, L.G.: Modelling Transport. Chichester : Wiley, 1990
Ortzar, J.D.; Willumsen, L.G.: Modelling Transport. Third edition.Chichester : Wiley, 2001
Salzwedel, J.: Untersuchungen zur Einordnung der verkehrsplanerischen Berechnung des Gter- und
Wirtschaftsverkehrs in das Modell- und Programmsystem PEVA. (Transportation planning
analyses) Dresden, Technische Universitt, Institut fr Verkehrsplanung und Strassenverkehr,
Diplomarbeit, 1997 (Degree dissertation)
Schiller, C.: Integration des ruhenden Verkehrs in die Verkehrsangebots- und
Verkehrsnachfragemodellierung. Scientific series of Institut fr Verkehrsplanung und
Straenverkehr of TU Dresden, Vol. 5, 1997 (Transport supply and Traffic demand modelling)
Schmiedel, R.: Bestimmung verhaltensorientierter Personenkreise fr die Verkehrsplanung. Karlsruhe,
Universitt (TH), Fakultt fr Bauingenieur- und Vermessungswesen, Diss., 1984
(Diisertationon Behaviour-oriented coverage)
Schnabel W.; Lohse, D.: Grundlagen der Straenverkehrstechnik und der Straenverkehrsplanung.
Berlin : Transpress VEB Verlag fr Verkehrswesen, 1980 (Foundations of Traffic Engineering
and Transportation Planning)
Schnabel, W.; Lohse, D.: Grundlagen der Straenverkehrstechnik und der Verkehrsplanung. Bd. Berlin :
Verlag fr Bauwesen, 1997 (Foundations of Traffic Engineering and Transportation Planning)
Sonntag, H.u.a.: Entwicklung eines Wirtschaftsverkehrsmodells. Bundesministerium fr Verkehr. Berlin,
1995 Forschungsbericht im Auftrag des Bundeministeriums fr Verkehr (Commercial
transport model development)
718 PTV AG
Literature
Transportation Research Board: Highway Capacity Manual, Washington, DC, 2000.
Transportation Research Board: Highway Capacity Manual, Washington, DC, 2010.
U.S.Bureau of Public Roads (publisher): Traffic Assignment Manual.Washington, D.C.: U.S. Department
of Commerce, Bureau of Public Roads, 1964
719 PTV AG
List of illustrations
Illustration 1: VISUM network model and impact model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Illustration 2: Example of the temporal distribution of travel demand by four intervals of 30 minutes . . . . 6
Illustration 3: Network of the original version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Illustration 4: Network of the version used for version comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Illustration 5: Network with version comparison: The volumes of both versions compared as well their
difference is displayed. Verscomp is the name of the version comparison.. . . . . . . . . . . . . 11
Illustration 6: Network 1 for the merge network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Illustration 7: Network 2 for the merge network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Illustration 8: Merge network of network 1 and network 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Illustration 9: Connection between transport systems, modes, demand segments and demand matrices .
22
Illustration 10: Example of a TURNSTANDARD table in the network file which is used to specify standard
values for turn penalties and turn capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Illustration 11: Rank of the link type and its resulting major flows (yellow), flow hierarchy (red) . . . . . . . 30
Illustration 12: Examples for defining transport systems of a link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Illustration 13: Example for the different speeds of two PrT transport systems depending on the volume .
32
Illustration 14: Transportation demand between zones illustrated in the transport network and as a demand
matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Illustration 15: Supply of the travel demand via connectors to the network . . . . . . . . . . . . . . . . . . . . . . . 35
Illustration 16: Possibilities for modeling connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Illustration 17: Intersection area with multiple nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Illustration 18: Node and link types of main nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Illustration 19: Main turns open to traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Illustration 20: Main turns not open to traffic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Illustration 21: The stop hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Illustration 22: Possibilities of modeling stop points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Illustration 23: The line hierarchy used to model the PuT supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Illustration 24: Example for two line routes of a line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Illustration 25: Example for two time profiles of a line route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Illustration 26: Lengths in VISUM and their coherence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Illustration 27: Assignment of run times in VISUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Illustration 28: Example for the aggregation of line routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Illustration 29: Examples: Coupling two and three line routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Illustration 30: Calculation example for the calculation of indicators in case of couplings . . . . . . . . . . . . 57
Illustration 31: Reachability analyses for secondary schools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Illustration 32: Allocating POIs to links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Illustration 33: Visualization of the local position of count locations with the date of the count . . . . . . . . 62
Illustration 34: The Congestion Charge in London is an area toll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Illustration 35: Summation and average calculations with screenlines. . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Illustration 36: Calculation of the urban traffic volume with screenlines . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Illustration 37: Time series by percentage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Illustration 38: Time series of matrix numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Illustration 39: The relationship between the different analysis time intervals . . . . . . . . . . . . . . . . . . . . . 76
Illustration 40: Assignment not possible because the validity of the demand and the assignment time
720 PTV AG
interval do not overlap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Illustration 41: The demand between 6:30 and 7:30 am is assigned. . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Illustration 42: The demand between 6:30 and 7:30 am is assigned. . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Illustration 43: Structural data of zones stored in user-defined attributes . . . . . . . . . . . . . . . . . . . . . . . . 88
Illustration 44: Count data stored in user-defined link attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Illustration 45: Generating a subnetwork with stop point matrices regarding path legs and stop point
matrices regarding paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Illustration 46: Positive and negative surfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Illustration 47: Correlations between different demand objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Illustration 48: Integrated four-stage demand model in VISUM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Illustration 49: Extended four-stage model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Illustration 50: Modeling through decision tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Illustration 51: Daily time series for origin-destination groups of HW and WH (SrV 1987 Dresden) . . . 119
Illustration 52: EVA1 function in dependence of impedance w . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Illustration 53: EVA2 function in dependence of the parameters a and b . . . . . . . . . . . . . . . . . . . . . . . 140
Illustration 54: Impedance calculation for a PuT connection, for clarity illustrated in the unit [min] . . . . 192
Illustration 55: Example network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Illustration 56: VD function type BPR according to the Traffic Assignment Manual. . . . . . . . . . . . . . . . 204
Illustration 57: VD function type INRETS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Illustration 58: VD function type LOHSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Illustration 59: Capacity analysis process for signalized nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Illustration 60: Method of calculation at two-way stops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Illustration 61: Calculation process for an All-Way stop node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Illustration 62: Calculation process for roundabouts according to HCM 2010 . . . . . . . . . . . . . . . . . . . . 251
Illustration 63: Approaching flows at a four-leg roundabout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Illustration 64: Calculation process for roundabouts according to the TRL/Kimber method . . . . . . . . . 255
Illustration 65: Description of the node geometry for the TRL/Kimber model . . . . . . . . . . . . . . . . . . . . 256
Illustration 66: Example network for signal coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Illustration 67: Green time split at all nodes with succeeding left turns . . . . . . . . . . . . . . . . . . . . . . . . . 264
Illustration 68: A path through the example network passes SCs at nodes 7003, 8003, 8002 and 9002 . . .
265
Illustration 69: Progression quality for approach West at node 8003. . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Illustration 70: Progression quality for approach North at node 8002 . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Illustration 71: Example network for proportional distribution of the traffic demand. . . . . . . . . . . . . . . . 273
Illustration 72: Blocking back model, phase 1: Formation of congestion Iteration steps 1 and 2. . . . . . 280
Illustration 73: Blocking back model, phase 1: Formation of congestion Iteration step 3, route 1 . . . . . 280
Illustration 77: Blocking back model, phase 2, relief of congestion. Initial situation. . . . . . . . . . . . . . . . 282
Illustration 78: Blocking back model, phase 2, relief of congestion. Iterations step 1, route 1. . . . . . . . 283
Illustration 79: Blocking back model, phase 2, relief of congestion. Iteration step 1, route 2. . . . . . . . . 283
Illustration 84: Integral indicating the overall wait time over the interpolated measured queue lengths 287
Illustration 85: Parameterization of the Kirchhoff distribution model . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Illustration 86: Parameterization of the Logit distribution model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
721 PTV AG
Illustration 87: Parameterization of the Box-Cox distribution model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Illustration 88: Parameterization of the Lohse distribution model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Illustration 89: Distribution with variable beta according to the modified Kirchhoff rule
(please refer to Schnabel / Lohse) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Illustration 90: Parameterization of the Lohse distribution model with variable Beta . . . . . . . . . . . . . . . 294
Illustration 91: Procedure of the incremental assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Illustration 92: Example network for the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Illustration 93: Procedure of the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Illustration 94: Procedure of the network balancing for an OD pair in the equilibrium assignment. . . . . 310
Illustration 95: Linear User Cost Equilibrium between two paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Illustration 96: Numerical example of the procedure to obtain the descent direction . . . . . . . . . . . . . . . 320
Illustration 97: Numerical example of the procedure to obtain the descent direction . . . . . . . . . . . . . . . 321
Illustration 98: Procedure of the Equilibrium_Lohse assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Illustration 99: ICA-based impedance calculation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Illustration 100: Procedure of the assignment with ICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Illustration 101: Turn volume delay function of the assignment with ICA . . . . . . . . . . . . . . . . . . . . . . . . 341
Illustration 102: Procedure of the stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Illustration 103: Discarding routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Illustration 104: Example for similarity of routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Illustration 105: Volumes and link run times after the first internal iteration step m=1 . . . . . . . . . . . . . . 352
Illustration 106: Example for area toll : The London Congestion Charging Zone . . . . . . . . . . . . . . . . . . 357
Illustration 107: Reducing the area toll to the link toll case
(For clarity reasons, turns without toll are not displayed) . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Illustration 108: Toll station at highway exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Illustration 109: Example of a matrix toll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Illustration 110: Shortest path search graph with matrix toll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Illustration 111: Time-cost diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Illustration 112: Density function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Illustration 113: Distribution function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Illustration 114: Path Search. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Illustration 115: Distribution of the traffic demand onto the routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Illustration 116: Equilibrium formation with TRIBUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Illustration 117: Attribute selection for the Toll systems list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Illustration 118: Attribute selection for the Toll matrices list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Illustration 119: The dynamic user equilibrium problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Illustration 120: Time slice approach (left side) and time profile approach (right side) to the Continuous
Dynamic Network Loading problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Illustration 121: Scheme of the fixed point formulation for the WDDTA with spillback congestion. . . . . 369
Illustration 122: Recursive expressions of path exit time, entrance time and cost . . . . . . . . . . . . . . . . . 372
Illustration 123: The adopted parabolic-trapezoidal fundamental diagram, expressing the relation among
vehicular flow, speed and density along a given arc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Illustration 124: The trapezoidal fundamental diagram suggested for urban links . . . . . . . . . . . . . . . . . 374
Illustration 125: Scheme of the fixed point formulation for the NPM. . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Illustration 126: Arc with time-varying capacity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Illustration 127: Flow pattern given by the Simplified Theory of Kinematic Waves. . . . . . . . . . . . . . . . . 378
Illustration 128: Flow pattern given by the Averaged Kinematic Wave model . . . . . . . . . . . . . . . . . . . . 379
Illustration 129: Determination of the arc hypocritical exit time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Illustration 130: Trajectories of a hypercritical kinematic wave and of the intersecting vehicles . . . . . . 382
Illustration 131: Graphical determination of the time series of the inflow capacity in the case of triangular
722 PTV AG
fundamental diagram, piecewise constant inflow, and constant exit capacity. . . . . . . . . . . 383
Illustration 132: Dynamic version of the Bellman relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Illustration 133: Variables and models of the fixed point formulations for the network performance model
(left hand side) and for the dynamic assignment with spillback (right hand side) . . . . . . . . 387
Illustration 134: Example network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Illustration 135: Results of WDDTA without and with spillback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Illustration 136: Shape of the fundamental diagram based on the link attributes . . . . . . . . . . . . . . . . . 392
Illustration 137: Parabolic sub-critical branch in the fundamental diagram . . . . . . . . . . . . . . . . . . . . . . 393
Illustration 138: Signalized intersection in reality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Illustration 139: Diagram of the signalized node in VISUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Illustration 140: Example of the impedance calculation of a connection . . . . . . . . . . . . . . . . . . . . . . . . 398
Illustration 141: Example of the network volume along a connection . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Illustration 142: Procedure of the dynamic stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Illustration 143: Different modeling options for main and subordinated networks . . . . . . . . . . . . . . . . . 408
Illustration 144: Timetable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Illustration 145: Line map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Illustration 146: Example network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
Illustration 147: Example for skim value calculation for partially traversed links . . . . . . . . . . . . . . . . . . 428
Illustration 148: Network volume after transport system-based assignment (parameters file TSys1.par) . . .
429
Illustration 149: Network volume after transport system-based assignment (parameters file TSys2.par) . . .
430
Illustration 150: Example network for choice models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Illustration 151: Structure of the choice in scenario 1 (no information) . . . . . . . . . . . . . . . . . . . . . . . . . 442
Illustration 152: Structure of the choice in scenario 2 (local information). . . . . . . . . . . . . . . . . . . . . . . . 443
Illustration 153: Structure of the choice in scenario 3 (information in the vehicle) . . . . . . . . . . . . . . . . . 444
Illustration 154: Volume for headway-based assignment, transfer penalty 2 min . . . . . . . . . . . . . . . . . 448
Illustration 155: Coordination of lines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Illustration 156: Network volume for timetable-based assignment (parameter file timetab1.par) . . . . . 465
Illustration 157: Flow chart of a timetable-based assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Illustration 158: Standard questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Illustration 159: Processing of PuT passenger surveys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Illustration 160: Validity check of the survey path leg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Illustration 161: Validity check of the preceding section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Illustration 162: Territories in the example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Illustration 163: Line 2 traverses several territories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Illustration 164: Allocation of vehicles and operators in the line hierarchy. . . . . . . . . . . . . . . . . . . . . . . 499
Illustration 165: Example line block with pull-out trip, interlining trip and pull-in trip . . . . . . . . . . . . . . . 501
Illustration 166: Conflict between empty trips and vehicle demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
Illustration 167: Line network of the example with three bus lines (red, blue and yellow) . . . . . . . . . . . 505
Illustration 168: (Graphical) timetable of the example, color codes as above . . . . . . . . . . . . . . . . . . . . 505
Illustration 169: Covering the timetable through pure line blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
Illustration 170: Covering the timetable through blocks without empty trips . . . . . . . . . . . . . . . . . . . . . 509
Illustration 171: Covering the timetable through line comprehensive blocks with empty trips . . . . . . . . 511
Illustration 172: Unsymmetrical timetable with trips beyond 24 hours . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Illustration 173: Blocking days and vehicle demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Illustration 174: State model for blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
Illustration 175: Example for partitioning according to vehicle combination and operator . . . . . . . . . . . 529
Illustration 176: Inserting the nodes and edges for vehicle journey sections. . . . . . . . . . . . . . . . . . . . . 530
723 PTV AG
Illustration 177: Inserting the edges for entering the depots and for empty trips between stop points . . 531
Illustration 178: Inserting the edges for leaving from depots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
Illustration 179: Example graph after inserting the timeline edges and edge reduction . . . . . . . . . . . . . 533
Illustration 180: Optimal cost flow in the example graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
Illustration 181: Example 1 for the decomposition into blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
Illustration 182: Example 2 for the decomposition into blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
Illustration 183: Example for block display of a block with 5 blocking days . . . . . . . . . . . . . . . . . . . . . . 543
Illustration 184: Possibilities of fare modeling in VISUM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Illustration 185: Example for a distance-based fare with 5 fare stages . . . . . . . . . . . . . . . . . . . . . . . . . 551
Illustration 186: Example for a zone-based fare with three covering fare zones and six stops. . . . . . . . 553
Illustration 187: Example network with two lines and volume data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
Illustration 188: Calculation of service kilometers between 8 a.m. and 9 a.m. . . . . . . . . . . . . . . . . . . . . 579
Illustration 189: Calculation of passenger kilometers between 8:00 a.m. and 9:00 a.m. . . . . . . . . . . . . 583
Illustration 190: Calculation of passenger kilometers between 8 a.m. and 9 a.m. . . . . . . . . . . . . . . . . . 584
Illustration 191: Calculation schema for costs and revenues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Illustration 192: Calculation of the fare points for path legs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Illustration 193: Example network for fixed amount per path leg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Illustration 194: Time-distance diagram for a vehicle journey with two vehicle journey sections . . . . . . 605
Illustration 195: Aggregation along the line hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
Illustration 196: Aggregation of the service kilometers from the trips onto the line. . . . . . . . . . . . . . . . . 607
Illustration 197: Interpolation of passage times (run times in minutes) . . . . . . . . . . . . . . . . . . . . . . . . . . 608
Illustration 198: Partially traversed links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
Illustration 199: Influence of couplings on the indicator calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
Illustration 200: Extended projection of attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
Illustration 201: Illustration of noise volume as link bars. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
Illustration 202: Emissions relative to speed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Illustration 203: Display of nitrogen monoxide volumes as link bars . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
Illustration 204: Evaluation period and annuities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
Illustration 205: Depiction of the results in EWS window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
Illustration 206: Source and target attribute allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635
Illustration 207: Land use from two shape files as background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636
Illustration 208: Examples of overlapping network objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
Illustration 209: Intersecting three polygon objects with a link buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
Illustration 210: Intersecting point objects with a polygon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
Illustration 211: Intersecting point objects with a buffer polygon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
Illustration 212: Intersecting point object buffers with polygons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
Illustration 213: Legend with user-defined texts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
Illustration 214: VISUM network display without background. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
Illustration 215: VISUM network display with background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
Illustration 216: Display of the flow bundle paths in the PuT path leg list . . . . . . . . . . . . . . . . . . . . . . . . 656
Illustration 217: PuT node flow bundle with additional filter criteria for lines. . . . . . . . . . . . . . . . . . . . . . 658
Illustration 218: Some of the paths which traverse node 100001 and use line 002 . . . . . . . . . . . . . . . . 658
Illustration 219: Display of through traffic with a flow bundle of active links . . . . . . . . . . . . . . . . . . . . . . 660
Illustration 220: Paths which start in zone 102 and end in zones 1, 2 or 5. . . . . . . . . . . . . . . . . . . . . . . 663
Illustration 221: All paths which traverse a link section in north direction. . . . . . . . . . . . . . . . . . . . . . . . 664
Illustration 222: Combination of flow bundles for PrT and PuT by using an OR link . . . . . . . . . . . . . . . 665
Illustration 223: Link flow bundle with AND THEN term and OR link . . . . . . . . . . . . . . . . . . . . . . . . . . . 666
Illustration 224: Link flow bundle with alternative routes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667
724 PTV AG
Illustration 225: Isochrones to display the accessibility of stop areas . . . . . . . . . . . . . . . . . . . . . . . . . . 668
Illustration 226: Functional principle of isochrones with a simple example . . . . . . . . . . . . . . . . . . . . . . 669
Illustration 227: Accessibility of link sections from node 7357 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 670
Illustration 228: Zones classified according to their Isochrones time PrT . . . . . . . . . . . . . . . . . . . . . . . 671
Illustration 229: 2D display of the accessibility of stop areas from the main station . . . . . . . . . . . . . . . 672
Illustration 230: Classified display of stops on the basis of the isochrone time PuT . . . . . . . . . . . . . . . 673
Illustration 231: Classified display of stops on the basis of the isochrone number of transfers. . . . . . . 674
Illustration 232: Comparison of the accessibility in PrT and PuT in graphical display . . . . . . . . . . . . . . 675
Illustration 233: Comparison of the accessibility in PrT and PuT in the list view . . . . . . . . . . . . . . . . . . 675
Illustration 234: Shortest path search between two nodes in PrT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Illustration 235: Graphical and tabular display of link volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Illustration 236: Example for link lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
Illustration 237: PrT path list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684
Illustration 238: Link bars with PrT volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Illustration 239: Connector bars with PrT volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
Illustration 240: Two link bars with PrT and PuT volume. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
Illustration 241: Categorized link display according to link category . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
Illustration 242: Categorized link display according to saturation PrT . . . . . . . . . . . . . . . . . . . . . . . . . . 690
Illustration 243: Zone categorization according to origin traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691
Illustration 244: Link bar display categorized according to saturation PrT. . . . . . . . . . . . . . . . . . . . . . . 692
Illustration 245: Table display of boarding passengers, transfers and alighting passengers at stops . . 693
Illustration 246: Number of residents and workplaces per zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
Illustration 247: Display of the mode selection as pie charts for zones . . . . . . . . . . . . . . . . . . . . . . . . . 695
Illustration 248: Turn volume with display of turn volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696
Illustration 249: Desire line with bars scaled at the demand between zones. . . . . . . . . . . . . . . . . . . . . 697
Illustration 250: Desire line with bars classified according to the demand between zones . . . . . . . . . . 698
Illustration 251: Stop catchment areas with a large radius of 400m . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
Illustration 252: Stop catchment areas classified according to the number of departures. . . . . . . . . . . 700
Illustration 253: Lane allocation in the network display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
Illustration 254: Classified lane allocation according to the node volume . . . . . . . . . . . . . . . . . . . . . . . 701
Illustration 255: Isochrone view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
Illustration 256: Stops in the network display. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
Illustration 257: Regular services mode in the timetable editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
Illustration 258: Timetable network graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
Illustration 259: Column charts for time intervals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
Illustration 260: Column chart for relations between network objects . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Illustration 261: Tabular timetable in the standard view. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
Illustration 262: Tabular timetable in regular service mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
Illustration 263: Table background classified by revenue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
Illustration 264: Graphical timetable with classified display of trip line style properties . . . . . . . . . . . . . 711
Illustration 265: Item bars for trips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
Illustration 266: Classification of item bars with the trip volume. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
Illustration 267: Display of item bars for boarding passengers, through passengers and alighting
passengers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
725 PTV AG
List of tables
List of tables
Table 1: Additional attributes for a compared numerical attribute after version comparison . . . . . . . . . . . 9
Table 2: Basic network objects of a transport network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Table 3: PuT network objects of a transport network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Table 4: General network objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Table 5: PrT transport systems properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Table 6: Flow hierarchy symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Table 7: OD pairs in the example Example.ver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Table 8: Example for three service trips. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Table 9: Input data for the calculation example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Table 10: Calculation of indicators for the line route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Table 11: Calculation of indicators for the links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Table 12: Network objects of the Junction model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Table 13: Deriving projection factors for AP and AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Table 14: Example for the interaction of analysis time intervals and time series . . . . . . . . . . . . . . . . . . . 77
Table 15: Examples of input and output attributes at the link. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Table 16: Example for a 1..1 relation in the VISUM network model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Table 17: Example for a 0..1 relation in the VISUM network model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Table 18: Example for a 0..n relation with aggregate function Num. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Table 19: Example for a 0..n relation with aggregate function Min. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Table 20: Example for a 0..n relation with aggregate function Max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Table 21: Example for a 0..n relation with aggregate function Sum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Table 22: Example for a 0..n relation with aggregate function Avg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Table 23: Example for a 0..n relation with aggregate function Concatenate . . . . . . . . . . . . . . . . . . . . . . 86
Table 24: Example for a 0..n relation with aggregate function Histogram . . . . . . . . . . . . . . . . . . . . . . . . 87
Table 25: Saving the cost per kilometer to a user-defined attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Table 26: Time-varying attributes and their allocation to assignment procedures . . . . . . . . . . . . . . . . . . 90
Table 27: Impact of time-varying attributes in the Dynamic Stochastic assignment. . . . . . . . . . . . . . . . . 92
Table 28: Table Main nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Table 29: Table Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Table 30: Table Surface items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Table 31: Table Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Table 32: Table Face items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Table 33: Table Edges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Table 34: Table Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Table 35: Table Intermediate points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Table 36: Examples for the normalization of surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Table 37: Typical break-down of a demand stratum into 8 activities and 17 demand strata = activity pairs
119
Table 38: Examples of relevant structural properties and person groups of the demand strata . . . . . . 120
Table 39: Trip generation in EVA model: OD type 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Table 42: List of the activity chains: mobility rates per person group in %. . . . . . . . . . . . . . . . . . . . . . . 146
Table 43: Basic matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
726 PTV AG
List of tables
Table 44: Result matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Table 45: Abbreviations used in the User model PrT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Table 46: Example network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Table 47: Link-based PrT paths of a PrT assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Table 48: Variables used in VD functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Table 49: Parameters for all VD functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Table 50: VD function type BPR2: modified BPR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Table 51: VD function type BPR2: modified BPR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Table 52: VD function type CONICAL (Spiess) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Table 53: VD function type CONICAL_MARGINAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Table 54: VD function type EXPONENTIAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Table 55: VD function type INRETS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Table 56: VD function types LOGISTIC, QUADRATIC, SIGMOIDAL_MMF_NODES,
SIGMOIDAL_MMF_LINKS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Table 57: VD function type AKCELIK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Table 59: VD function type ICA-Turn (illustration 100, query 2: Is the turn share T below p
2
?) . . . . . . 207
Table 58: VD function type AKCELIK2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Table 60: VD function type LOHSE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Table 61: VD function type Linear Bottleneck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Table 62: Input data of the calculation of the link impedance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Table 63: Car travel times and speeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Table 64: HGV travel times and speeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Table 65: Calculation of link impedance for HGV and car. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Table 66: Advantages and disadvantages of the node impedance model . . . . . . . . . . . . . . . . . . . . . . 210
Table 67: Attributes for the impedance calculation from Turns VD function . . . . . . . . . . . . . . . . . . . . . 212
Table 68: Attributes for the impedance calculation from Node VD function . . . . . . . . . . . . . . . . . . . . . 212
Table 69: Attributes for the calculation regarding uncontrolled nodes. . . . . . . . . . . . . . . . . . . . . . . . . . 214
Table 70: Input attributes for signalized nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Table 71: Output attributes for signalized nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Table 72: Input attributes for the calculation of two-way stops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Table 73: Ranking of movements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Table 74: Calculation of the conflicting volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Table 75: Base values for the critical gap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Table 76: Follow-up times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Table 77: Impeding movements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Table 78: Allocation of a LOS to the mean delay per vehicle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Table 79: Input attributes for an All-Way stop node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Table 80: Adjustment factors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Table 81: Probability states calculation of degree-of-conflicts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Table 82: Excerpt from the DOC table for two lanes per approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Table 83: Lookup table base follow-up time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Table 84: Base values for the saturation follow-up time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Table 85: Determining the LOS based on the mean delay per vehicle . . . . . . . . . . . . . . . . . . . . . . . . . 250
Table 86: Input attributes for roundabout nodes according to HCM 2010. . . . . . . . . . . . . . . . . . . . . . . 251
Table 87: LOS per lane based on the mean delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Table 88: Input attributes for calculation according to the TRL/Kimber method . . . . . . . . . . . . . . . . . . 256
Table 89: LOS for calculation according to Kimber based on the mean delay . . . . . . . . . . . . . . . . . . . 259
Table 90: Input attributes with effect at signal coordination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
727 PTV AG
List of tables
Table 91: Output attributes for signal coordination results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Table 92: Procedure parameters for signal coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Table 93: PrT skims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Table 94: Aggregation functions for the skim data calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Table 95: Parameters for the distribution with variable beta in illustration 89 . . . . . . . . . . . . . . . . . . . . 294
Table 96: Distribution to two alternatives with the impedances 5 and 10. . . . . . . . . . . . . . . . . . . . . . . . 295
Table 97: Distribution for two alternatives with impedance 105 and 110 . . . . . . . . . . . . . . . . . . . . . . . . 295
Table 98: Distribution for two alternatives with impedance 50 and 100 . . . . . . . . . . . . . . . . . . . . . . . . . 296
Table 99: Model parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Table 100: Example of the incremental assignment (BPR function a=1, b=2, R=tCur) . . . . . . . . . . . . . 298
Table 101: Input attributes for the incremental assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Table 102: Output attributes of the incremental assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Table 103: Calculation of the user optimum for the example network . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Table 104: Calculation of the system optimum for the example network . . . . . . . . . . . . . . . . . . . . . . . . 302
Table 105: Example network for the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Table 106: Assignment results for the three PrT paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Table 107: Assignment result at the links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Table 108: Input attributes of the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Table 109: Output attributes of the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Table 110: Example equilibrium procedure (BPR function a=1, b=2) . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Table 111: Impedance in unloaded network, input parameters of Equilibrium_Lohse method . . . . . . . 325
Table 112: Example of Equilibrium_Lohse: 1. Iteration Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Table 115: Input attributes of the Equilibrium_Lohse procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Table 116: Output attributes of the Equilibrium_Lohse procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Table 117: Input attributes of the assignment with ICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Table 118: Additional attributes of turns and main turns for assignment with ICA. . . . . . . . . . . . . . . . . 336
Table 119: Output attributes of the assignment with ICA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Table 120: Input attributes for the stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Table 121: Output attributes for the stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Table 122: Impedance in the unloaded network, input parameters for stochastic assignment . . . . . . . 350
Table 123: Calculation of the commonality factor C for all route pairs . . . . . . . . . . . . . . . . . . . . . . . . . 351
Table 124: Volumes in the first internal iteration step m = 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Table 125: Volumes in the second internal iteration step m = 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Table 126: Input attributes for TRIBUT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Table 127: Output attributes for TRIBUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Table 128: Toll amounts for the example network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Table 129: Comparison of conventional toll assignment and TRIBUT . . . . . . . . . . . . . . . . . . . . . . . . . 360
Table 130: Input attributes for the DUE procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Table 131: Example of the Dynamic user equilibrium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Table 132: Output attributes of the Dynamic user equilibrium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Table 133: Input attributes of the dynamic stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Table 134: Output attributes of the dynamic stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Table 135: Calculation rules for the output attributes of the assignment analysis . . . . . . . . . . . . . . . . . 404
Table 136: Demand matrix and temporal distribution of demand for the example. . . . . . . . . . . . . . . . . 410
Table 137: PuT supply of the example with connections from A-Village to X-City. . . . . . . . . . . . . . . . . 411
Table 138: Path legs after a timetable-based assignment (paths saved as connections) . . . . . . . . . . . 413
728 PTV AG
List of tables
Table 139: Path legs after a timetable-based assignment (paths saved as routes). . . . . . . . . . . . . . . 413
Table 140: Skims of time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Table 141: Skims of length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Table 142: Monetary skims [Currency units] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Table 143: Skims of frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Table 144: Skims of attribute data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Table 145: Derived skims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Table 146: Example of the connection skims of an OD pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
Table 147: Availability of the skims in the PuT assignment procedures . . . . . . . . . . . . . . . . . . . . . . . . 421
Table 148: Combination of skim data to the mean skim value per OD pair . . . . . . . . . . . . . . . . . . . . . 422
Table 149: Example for the determination of the time difference DT . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Table 150: Comparison of the impedance functions in the PuT assignments. . . . . . . . . . . . . . . . . . . . 426
Table 151: Connector weights for the example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Table 152: Temporary demand matrix for the assignment in the example . . . . . . . . . . . . . . . . . . . . . . 427
Table 153: Example for headway calculation from mean headway according to timetable . . . . . . . . . 432
Table 154: Example for headway calculation from mean wait time according to timetable . . . . . . . . . 433
Table 155: Considering elapsed wait time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Table 156: Travel times and headways of the lines in the example network . . . . . . . . . . . . . . . . . . . . 444
Table 157: Line shares and the mean costs depending on the information available. . . . . . . . . . . . . . 445
Table 158: Headway calculation for the example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Table 159: Impedance calculation for the routes in the example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Table 160: Changes to shares with variation of the transfer penalty. . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Table 161: Mean indicators for the headway-based assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Table 162: Calculation of the temporal distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Table 163: Procedure parameters for the comparison of the distribution models. . . . . . . . . . . . . . . . . 462
Table 164: Example 1 Initial situation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Table 165: Example 2 Isochronous, identical pair of connections . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Table 166: Example 3 Identical pair of connections with high temporal proximity . . . . . . . . . . . . . . . 462
Table 167: Example 5 - Differing pair of connections with moderate temporal proximity . . . . . . . . . . . 463
Table 168: Result of connection search (transfer penalty 10 min, parameter file timetab1.par) . . . . . . 464
Table 169: Temporal distances T and impedances R of the connections for the two analyzed intervals of
travel demand. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Table 170: Distribution of trips to the connections (Kirchhoff, = 3). . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Table 171: Calculation rules for the output attributes of the assignment analysis. . . . . . . . . . . . . . . . . 476
Table 172: Status indicators for the surveyed path leg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
Table 173: Status indicators for the preceding section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
Table 174: Status indicators for the succeeding section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
Table 175: Status indicators for the entire survey data record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
Table 176: Level Territory x Transport system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Table 177: Indicators for line route analysis by territory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Table 178: Territory-based indicator data for transport performance and revenue analysis. . . . . . . . . 493
Table 179: Territory-based analysis on aggregation level Territory x Line . . . . . . . . . . . . . . . . . . . . . . 494
Table 180: Analysis of the Vol/Cap ratio of seats on the line route level. . . . . . . . . . . . . . . . . . . . . . . . 495
Table 181: Service kilometer analysis on the level of lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Table 182: Cost and revenue computation on the level of lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Table 183: Evaluation of transport performance indicators on the level of operators . . . . . . . . . . . . . . 497
Table 184: Evaluation of service kilometers per time interval for the bus operator . . . . . . . . . . . . . . . . 497
Table 185: PassengerKm-to-ServiceKm ratio for the Bus operator . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
729 PTV AG
List of tables
Table 186: Example line block with pull-out trip, interlining trip and pull-in trip . . . . . . . . . . . . . . . . . . . 502
Table 187: Block data of the three approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
Table 188: Block items of the line blocks in block version 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
Table 191: Open block and closed block for the unsymmetrical example (illustration 172) . . . . . . . . . . 514
Table 192: Block items of both blocks in the example Block items in the recurring rhythm were omitted for
a better overview. Block 1 is open, block 2 is closed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Table 193: Block version attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Table 194: Block attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Table 195: Block item attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Table 196: Block item type attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
Table 197: Attributes of the line blocking cost function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
Table 198: Depot attributes of stop points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
Table 199: Cost rates for downtimes at depots and stop points at vehicle unit (cost rates in Table 197 refer
to this) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
Table 200: Cost rates for downtimes at depots and stop points at the vehicle combination (cost rates in
Table 197 refer to this) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
Table 201: Objective function components for line blocking with vehicle interchange . . . . . . . . . . . . . 541
Table 202: Line blocking and vehicle requirement indicators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Table 203: Example illustrating different variants of distribution of empty time and empty kilometers on in-
dividual service trips. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Table 204: PuT interlining matrix with t-PuTSys between stop points . . . . . . . . . . . . . . . . . . . . . . . . . . 546
Table 205: Linking fare systems and demand segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
Table 206: Transport supply in Example_LLE.ver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
Table 207: Projection factors for the valid days in Example_LLE.ver . . . . . . . . . . . . . . . . . . . . . . . . . . 570
Table 208: Projection factor for the demand segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570
Table 209: Total capacity provided in the vehicles of example Example_LLE.ver. . . . . . . . . . . . . . . . . 570
Table 210: Fare model in Example_LLE.ver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570
Table 211: Fares of the fare model in Example_LLE.ver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
Table 212: Transport demand between the zones in Example_LLE.ver . . . . . . . . . . . . . . . . . . . . . . . . 571
Table 213: Cost rates for vehicles in Example_LLE.ver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
Table 214: Indicators for line route and timetable evaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
Table 215: Indicators of the transport supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
Table 216: Indicators of the network performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
Table 217: Vehicle type-dependent costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Table 218: Infrastructure costs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Table 219: Total costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Table 220: Cost rates for the vehicle units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
Table 221: Cost rates for the vehicle combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
Table 222: Distances and times for the vehicle combination Train in the analysis period . . . . . . . . . . . 588
Table 223: Formulas for calculating link costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Table 224: Example calculation for link depreciation costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Table 225: Example calculation for running costs of links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
Table 226: Example calculation for link utilization costs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
Table 227: Formulas for the calculation of stop point costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Table 228: Formulas for calculating operator costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Table 229: Calculation example for depreciation costs of the operator . . . . . . . . . . . . . . . . . . . . . . . . . 593
Table 230: Calculation example for the running costs of the operator . . . . . . . . . . . . . . . . . . . . . . . . . . 593
730 PTV AG
List of tables
Table 231: Revenue indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
Table 232: Revenue share per path leg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
Table 233: Revenue per line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Table 234: Revenue share per path leg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Table 235: Revenue per line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Table 236: Calculation of the revenues per path (PuT routes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Table 237: Revenue calculation for the path leg Bus1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
Table 238: Aggregation of the path leg revenues to lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Table 239: Input data for the calculation example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Table 240: Revenue distribution W-NumFP = 1.0, W-NumPL= 0.0, FixSuppl = 0 . . . . . . . . . . . . . . . . 601
Table 241: Revenue distribution W-NumFP = 0.5, W-NumPL = 0.5 , FixSuppl = 0.00 . . . . . . . . . . . . . 601
Table 242: Revenue distribution W-NumFP = 0.5, W-NumPL = 0.5 , FixSuppl = 0.20 . . . . . . . . . . . . . 601
Table 243: Indicators for the cost coverage calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Table 244: Cost coverage calculation from revenues and costs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Table 245: Which projection factor applies for the calculation of indicators? . . . . . . . . . . . . . . . . . . . . 603
Table 246: Difference in the projection to AH for ServiceKm and PassengerKm . . . . . . . . . . . . . . . . . 603
Table 247: Further specifications for the vehicle journey with two VJ sections. . . . . . . . . . . . . . . . . . . 605
Table 248: Calculation of seat kilometers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
Table 249: Calculation of service kilometers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
Table 250: Link attributes for noise calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
Table 251: Pollutant-Emis link attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
Table 252: EWS-specific link attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
Table 253: Reading shape files in VISUM network objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
Table 254: Illustration of VISUM files of shape types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
Table 255: Calculating the number of PuT passengers per zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
Table 256: Calculating the number of inhabitants in the catchment area of lines . . . . . . . . . . . . . . . . . 640
Table 257: Calculating the number of inhabitants in the catchment area of stops . . . . . . . . . . . . . . . . 641
Table 258: Calculating the vehicle kilometers within territories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
Table 259: Calculating the zone number where a stop point lies (). . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
Table 260: Calculating the average number of PuT passengers at the stops of a zone. . . . . . . . . . . . 642
Table 261: Planar coordinate system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
Table 262: Geometric coordinate system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
Table 263: Background formats supported by VISUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
Table 264: Example for a World file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
Table 265: The flow bundle as path filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
Table 266: Traffic types against the status (active / passive) of the path legs . . . . . . . . . . . . . . . . . . . 661
Table 267: Meaning of traffic types in path filters for active time profiles . . . . . . . . . . . . . . . . . . . . . . . 661
Table 268: Territory lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
Table 269: Stop lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682
Table 270: Item lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
Table 271: Line lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
Table 272: Block lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
Table 273: Evaluation lists for paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684
Table 274: Statistical evaluation lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685
PTV AG 755
Index
Index
A
Activities 5, 106
attributes (EVA) 115
Activity chains 107, 144, 146
Activity pairs 5, 107
Air pollution emissions 616
pollution-Emis procedure 616
Akcelik (VD function) 206
Analysis
analysis horizon 75
analysis period 75
analysis time intervals 75, 76, 79
Annual calendar 72
Assessment types 136
Assignment
distribution models 289
PuT procedure
see PuT assignment procedure
Assignment analysis
PrT 403
PuT 475
Assignment procedure
see Assignments
Assignment quality 288
Assignment time interval 75
Assignments
demand segments 25
PrT procedures
see PrT assignment procedure
Attraction 111, 118, 122, 134
Attributes
direct 81
indirect 82
time-dependant 90
user-defined 87
Average Excess Cost AEC (PrT assignment qua-
lity) 288
B
Background formats 651
Backgrounds 649
automatic positioning 652
Bar display 7, 686
Best-route assignment 296
Block check 525
forced 527
general 527
Block element types 519
Block elements 519
Block version 515
Blocking-back model 273
Blocks 516
Bounding 454
Box-Cox model 291
BPR (VD function) 204
Branch and Bound 453
Buffer 642
C
Calculate skim matrix (procedure) 271
Calculated results
temporal distinction 79, 80
Calendar 45, 72
Calendar period 75
Capacities
adjust to demand values 80
Cascetta 347
Charts 7
column charts 694, 706
pie charts 695
C-Logit approach 347
Column charts 8, 706
Commonality factor 347
Complex terms
add 173
Conical (VD function) 204
Conical marginal (VD function) 205
Connection choice
timetable-based assignment 458
Connection search 453
Connections
distribute traffic demand
PrT 272
PuT 426
independence (Timetable-based assignment)
756 PTV AG
Index
460
indicators 415
Connectors 34
destination connector 34
distribute traffic demand
PrT 35
PuT 35
impedances 201
multi point assignment (MPA) 35
origin connector 34
Constant from time profile attribute (Headway cal-
culation) 432
Constraints 122, 145
Controller types at node 213
Co-ordinate systems 646
Coordination groups 449
Cordon links 37
Cost (PuT) 584
Cost-benefit analyses
see Modal Split
Cost-Benefit Analysis 625, 630
Cost-benefit ratio (CBR) 626
Count locations 61
Coupling time profiles 55
Crosswalk 69
Cycle time optimization 260
D
deltaT 457
early 457
late 457
Demand
see transport demand
Demand matrices 3, 104
updating 179
Demand model structure 105
Demand models 1, 3
activity based
see Demand models, VISEM model
EVA model for passenger demand 4, 115
standard four-stage model 4, 110
time series 5
VISEM model 5, 144
Demand objects 5, 103
Demand segments 22, 24, 104
Demand strata 5, 108
attraction 111, 118, 122, 134
demand strata 134
home trips 147
production 111, 118, 122, 134
Desire lines 696
Detectors 61
Difference network
analysis time intervals 15
examples 12
see network merge
Direct assignment 487
Display
2D 702
Display turn volumes 7, 695
Distribution models 289
box-Cox model 291
kirchhoff model 290
logit model 290
lohse model 292
with variable Beta 293
with independence 461
DMRB guideline TD 16/93 (roundabouts) 255
Dominance 453
Duality gap (PrT assignment quality) 288
DUE 367
Dynamic equilibrium assignment (DUE) 367
Dynamic stochastic assignment 396
input and output attributes 399
procedure 400
Dynamic User Equilibrium (DUE) 367
evaluation 367
E
Economic assessment 625
Edge 96
Environmental impact model 613
air pollution emissions 616
noise volume 613
Equilibrium assignment 301
evaluation 302
examples 303, 311
procedure 307
Equilibrium_Lohse 342
evaluation 331
examples 325
procedure 330
PTV AG 757
Index
E-ticketing 481
EVA
see EVA Model for Passenger Demand
EVA Model for Passenger Demand 103
activities 115
activity pairs 115
assessment types 136
balance factors 141, 144
balancing 126
constraints 122
demand strata 116
elasticity functions 138
evaluation 136
evaluation functions 135, 137
weighting probabilities Evaluation (EVA)
weighting probabilities 136
furness method
trilinear 141
home trips 134
mobility rates 121
mode choice 135
multi procedure
trilinear 141
structural properties 115
study area factors 121
trip distribution 135
trip generation 118
zones 117
EVA model for passenger demand 4, 115
Evaluate results 7
Evaluation (EVA) 136, 144
evaluation functions 135, 137
weighting Matrices 144
EWS-97 625
Excess emissions
calculation according to HBEFA 622
F
Face items 96
Faces 96
Fares 424
Flow bundle 7
Flow bundles 655
alternative routes 665
combine floe bundle criteria 662
display paths 665
flow bundle definition 657
link flow bundle 659
main node flow bundle 658
node flow bundles 657
select network objects 657
select transportation type 660
stop point, stop area, and stop flow bundle 659
zone and main zone flow bundle 659
Formula German 112
G
Geographic information systems (GIS) 633
Georeferenced 646
GIS objects 64, 633
Go to the operation (procedure) 4, 169
GPS tracking 653
Graphic display 679
Graphic objects 648
Graphical timetable 710
Gravity model 112, 157
calculate 157
calibrate 156
Green time optimization 260
H
HBEFA
Basis for calculating cold start excess emissi-
ons 622
Basis for calculating warm emissions 619
emission calculation 618
HBEFA-based emission calculation 618
HCM 213
Headway calculation
from mean headway 432
from mean wait time 433
Headway-based assignment 430
calculate headway 432
coordination 449
generalized costs 433
impedances 433
Highway Capacity Manual (HCM) 213
Histogram 172
Home trips 134, 147
Hypothetic vehicle impedance (PrT assignment
quality) 288
I
ICA 213
Impact Models
environmental impact model 191
758 PTV AG
Index
operator Model 190
user model 189
Impact models 1, 6, 189
Impedance
headway-based assignment 433
Impedance Functions 191
Impedance functions
at node 210
headway-based assignment 433
PrT assignments 200
timetable-based assignment 455
Impedances
connectors 201
examples 209
links 201
main turns 202
nodes 201
preloaded volume 202
routes 200
turns 201
Incremental assignment 296
evaluation 301
examples 296
procedure 298
Independence of connections 460
Indicators 193
calculate (PrT) 271
global indicators 194
PuT 415, 416, 417, 418
skim matrices 193
Indirect attributes
aggregation functions 83
average and AverageAktive 85
concatenate and ConcatenateActive 86
count and CountActive 83
frequency and FrequencyAktive 86
max and MaxAktive 84
min and MinActive 83
relations 82
sum and SumActive 84
INRETS (VD function) 206
Interactive analyses 655
flow bundles 655
isochrones 667
shortest path search 676
Intermediate points 96
Intersection Capacity Analysis (ICA) 213
all-way stop 243
Roundabouts 250
signalized nodes 214
two-way stop nodes 234
uncontrolled nodes 214
Isochrones 7, 667
combine PrT and PuT isochrones 674
PrT isochrones 669
PuT isochrones 671
J
Junction modeling 66
K
Kirchhoff model 290
L
Lane 68
Lanes
lane allocation 700
lane turn 69
Leg templates 69
Legend 648
Level of Service 242
Line blocking 500, 501
block check 525
block element and block element type 519
block version 515
blocks 516
check coverage 528
cost function 521
data model 504
depots 522
distribute empty trips and empty times 543
evaluation of the procedure 503
examples 504
lists 683
optimzation problem 502
procedure 529, 535
PuT interlining matrix 543
stand times 522
with vehicle interchange 538
Procedure runs 538
without vehicle interchange 528
Line hierarchy 45
data consistency 53
Line routes 46
PTV AG 759
Index
aggregate 54
edit shape with system routes 58
specify lengths 51
Linear bottle-neck (VD function) 208
Lines 46
Link orientations 67
Links 28
impedances 201
link types 29
major flows 29
permitted transport systems 30
PrT capacity 31
PrT speed 31
PrT travel time 31
PuT running time 32
specify lengths 51
specify link run time 51
Lists 7, 680
assignment analyses 685
couple sections 683
Coupling section items 683
emissions HBEFA 686
line blocks 683
block items 683
block lists 683
line block versions 683
line lists 683
line route items 683
lines 683
network information 685
OD pair lists 682
PrT
path sets 684
paths 684
paths on link level 684
quality assignment 685
quality assignment with ICA 685
PuT
assignment statistics 685
detail list 681
OD pairs 684
path legs 685
paths 684
PuT assignment statistics 685
stop lists 682
stop points - Arrivals/Dep. 682
system route items 683
territory lists 681
time profile items 683
Time profiles
Transition walk times 683
transfer walk times at stops 682
transfers 685
Transport systems
Transition walk times 683
vehicle journey items 683
Logit model (Distribution model) 290
Lohse (VD function) 208
Lohse model 292
with variable Beta 293
M
Main lines 46
Main nodes 36
Main relations 39
Main turns 38
impedances 202
Main zone matrices
disaggregate 175
Main zones 39
Major flows 29
Matched transfers 450
Matrices 3, 104
Add complex term 173
Adding columns or rows 176
aggregate 177
calibrate (PrT) 187
classify matrix values 172
correct 179
demand matrices 104
diagonal
extract 172
set 172
edit 170
functions 170
exponential function 173
extend 176
see Matrices, split
form reciprocal 173
forming maximum or minimum 173
gravity model
calculate 157
calibrate 156
logarithmic 173
matrices and combining vectors 173
760 PTV AG
Index
mean value upper/lower triangle 173
project 173
projecting path volumes (PrT) 187
raise to power 173
reflect 172
split 178
symmetrize 173
transpose 172
weighting Matrices 144
Matrix correction 179
calibrate matrix (PrT) 187
projecting path volumes (PrT) 187
TFlowFuzzy 179
Matrix Editor 170
Matrix editor 5, 104
Mean value
calculating
attributes 169
matrices 169
Merge network 13
Method of Successive Averages 169
Metropolis 402
Modal Split 165
Mode choice 4
nested (Standard four-stage model) 111, 114
standard four-stage model 113
VISEM model 151
Model transfer files 15
Models
compare 8
Modes 22, 24
MPA
see multi point assignment
MSA
see Method of Successive Averages
Multi Point Assignment 35
Multi procedure 157, 159, 174
trilinear (EVA) 141
N
NCHRP 255 402
Nested Mode Choice
see Mode choice, nested
Network check 71
Network display
bars 686
classified 688
Labeling with diagrams 693
Labeling with tables 692
Network merge 12
Network model 1, 2
Network objects
block 516
block element type 519
block elements 519
block item types 21
block version 515
block versions 21
buffer 642
connectors 18, 34
count locations 21, 61
demand segments 17, 22, 24, 104
detectors 22, 61
fare zones 21
GIS objects 22, 64, 633
intersect 638, 642
line blocking 504
line routes 20, 46
lines 20, 46
link types 18
links 18, 28
main lines 20, 46
main node 18
main nodes 36
main relations 39
main turns 18, 38
main zones 18, 39
modes 17, 22, 24
node 17
nodes 26
OD pairs 19
operator model (PuT) 498
paths 19, 40
points of interest (POI) 21, 59
PuT coordination groups 21
PuT operators 20, 44
PuT vehicles 45
screenlines 22, 64
stop areas 19, 43
stop points 19, 42
stops 19, 44
system routes 20, 58
territories 18, 40
ticket types 21
time profiles 20, 48
PTV AG 761
Index
toll systems 22
transport systems 17, 22, 23
trips 20
turning standards 18
turns 18, 26
valid days 19, 45, 72
vehicle combinations 20, 45
vehicle journey sections 20, 50
vehicle journeys 49
vehicle units 21, 45
zones 18, 32
Neworks
compare 8
Node
controller types 213
impedances 210
Node geometry 68
Node impedances 210
calculate according to HCM 213
node VD function (TModel) 212
turn VD function 212
Node legs 68
Node model 66
crosswalk 69
lane turn 69
lanes 68
leg templates 69
link orientations 67
node legs 68
node templates 69
node topology 68
signal control 70
Node templates 69
Node topology 68
display graphically 700
Node VD function (TModel) 212
Nodes 26
impedances 201
signal control 70
signal time optimization 260
traffic-related modeling 66
Noise volume 613
noise-Emis-Nordic procedure 613
noise-Emis-Rls90 procedure 613
the Noise-Emis-Nordic procedure 614
O
OD matrices
see Demand matrices
OD pairs 33
Operator model 498
Operator Model (PuT) 190
Operator model (PuT) 489
example 497
examples 491, 494
line blocking 500
network objects 498
parameters (aggregation levels) 490
territory section (aggregation levels) 493
work stages 499
Operators
in the operator model 498
Origin wait time (Timetable-based assignment)
456
P
Parameters 193
calculate aggregation levels 490
examples 491, 494, 497
territory section (aggregation levels) 493
Passenger survey 477
direct assignment 487
survey data
assignment 487
plausibilization 481
read 481
Path legs
PrT 199
PuT 412
Paths 40, 192
display (Flow bundles) 665
filter (Flow bundles) 655
PrT 199
PuT 412
Perceived journey time 424, 456
Person groups 5
Personal Geodatabase (PGD) 633
Pivot-Point model
see Modal Split
Point 96
Points of Interest (POI) 59
Pollution-Emis procedure 616
Polygons 652
Population groups 105
Procedure runs
Line blocking without vehicle interchange 528
762 PTV AG
Index
Production 111, 118, 122, 134
Projecting path volumes (PrT) 187
Projection 75
examples 76
Projections 646
PrT
path legs 199
path object 40
paths 199
PrT Assignment procedure
dynamic equilibrium assignment 367
dynamic stochastic assignment 396
metropolis assignment 402
toll 353
TRIBUT 353
PrT assignment procedure 195
convergence criteria 288
equilibrium assignment 301
Equilibrium_Lohse 342
incremental assignment 296
stochastic assignment 342
use solution as starting solution 202
VDR functions 202
PrT assignment procedures
impedance functions 200
PuT
operational indicators 545
analyze line route and timetable 572
calculate fare revenues 594
calculate transport performance 580
costs and revenue model 584
Distribute empty trips and empty times 543
examples 569, 593
hourly costs 587
kilometer costs 587
link costs 588, 589
measure transport supply 576
operating cost 584, 585
operator costs 591
stop point costs 590
vehicle costs 587
vehicle type costs 586, 587
operator 498
Operator model 6
operator model 498
operators 44
Passenger surveys 477
Path legs 412
paths 412
revenues 594
vehicles 45
PuT assignment procedure 407
PuT assignment procedures
headway-based 430
timetable-based 452
transport system-based 428
PuTAux transport system 465
Q
Queues 205
R
Ramp metering 205
RAS-W-86 625
Relative Gap RG (PrT assignment quality) 288
Revenue (PuT) 584
fares 424
RLS-90 613
Route search
transport system-based assignment 430
Route volume
transport system-based assignment 430
Routes
distribution of demand 289
impedances 200
indicators 415
S
SC 70
Screenlines 64
Shape files 634
Shortest path search 7, 454, 676
PrT 7, 676
PuT 7, 677
Signal control 70
stage templates 71
Signal controls 70
Signal coordination 262
Signal time optimization 260
Skim matrices 7
Skim matrices Matrices
skim matrices 104
Standard four-stage demand model 4, 110
Standard four-stage model 103, 111, 112
mode choice 113
nested 111, 114
PTV AG 763
Index
time-of-day choice 114
Standardized assessment
see Modal Split
Stochastic assignment 342
commonality factor 347
distribution models 289
evaluation 342
examples 350
Stop points 42
Stops 44
display catchment areas 698
hierarchies 41
zones 43
Structural properties 111
VISEM model 144
Subnetwork generator 93
Surface items 96
Surface model 93
multi-part surface 98
standardize surfaces 98
table 96
Surfaces 96
Survey data
assignment 487
plausibilization 481
read 481
System optimum 205, 302
System routes 58
T
Tables 7
Tabular display 679
Tabular timetable 707
tCur 202
Temporal utility 425
Territories 40, 80
Texts 648
TFlowFuzzy 179
The 453
Time profiles 48
coupling 55
specify run times 51
Time series 73, 105
examples 77
matrix numbers 5, 74, 105
percentage 5, 74, 105
Time-dependant attributes 90
Time-of-Day Choice
Timetable 53
Timetable editor 8, 707
evaluations 707
graphical timetable 710
tabular timetable 707
Timetable network graph 704
Timetable-based assignment 452, 458
connection choice 458, 463
connection preselection 455
connection search 453
branch and bound 453
distribution of trips for connections 459
evaluation 452
impedance 455
independence of connections 460
opening 466
perceived journey time 456
PuTAux transport system 465
temporal utility 425, 457
TModel 212
Toll in the assignment 353
Toll systems 63
Total Excess Cost TEC (PrT assignment quality)
288
Traffic demand 1, 3
distribute on PuT connections 426
distribute to PrT connections 272
model 1, 3
Traffic demand matrices
see demand matrices
Traffic demand model 1, 3
Transfer wait time (Timetable-based assignment)
456
Transport system-based assignment 428
evaluation 429
route search 430
route volume 430
Transport systems 22, 23
Transportation deman 103
model 109
Transportation demand 4
distribution on routes 289
time reference 73
time series 73
Transportation demand model 103
764 PTV AG
Index
TRIBUT procedure 353
Trip distribution 4, 112
VISEM model 147
Trip generation 4, 111
VISEM model 146
Trips 49
Turn VD function 212
Turns 26
Impedances 201
PrT capacity 28
PrT turn time 28
turn standards 27
turn types 27
U
User model 6
User optimum 205, 302
User-defined attributes 87
V
Valid days 45, 72
Value of time (VT) 355
VD functions 202
akcelik 206
BPR (according to Traffic Assignment Manu-
al) 204
conical 204
conical marginal 205
INRETS 206
linear bottle-neck 208
logistic 206
lohse 208
quadratic 206
SIGMOIDAL_MMF_LINKS 206
SIGMOIDAL_MMF_NODES 206
user-defined 209
Vehicle combination set 538
Vehicle combinations 45
Vehicle journey sections 50
Vehicle journeys 49
Vehicle units 45
Version comparison 9
Versions
compare 8
VISEM model 5, 103, 144
activity based model 144
constraints 145
destination choice 147
home trips 147
mode choice
combined 151
structural properties 144
trip distribution
combined 147
trip generation 146
utility function 148, 151
W
Weekly calendar 72
Weighting (EVA)
evaluation functions
BoxCox 138
Box-Tukey 138
combined 138
EVA1 137
EVA2 137, 140
kirchhoff 138
logit 138
schiller 137, 140
TModel 138
Weighting matrices 104
World files 652
Z
Zone matrices
aggregate 175
Zones 32
PTV AG 765
Index
Traffic Software
Logistics Software
Transport Consulting
PTV AG
Stumpfstr. 1
76131 Karlsruhe
Deutschland
Tel.: +49 721 9651-300
Fax: +49 721 9651-562
info.vision@ptv.de
www.ptv.de
www.ptvag.com
www.ptv-vision.de

PTV Visum-Fundamentals

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PTV Visum-Fundamentals

Uploaded by

Copyright:

Available Formats

VISUM 11.

64 There are 64 combinations for 4 legs each with 2 lanes.

6:00 7:00 , 2600

M = relevant hourly traffic volume (car/h)

You might also like