You are on page 1of 810

PTV VISUM 13

FUNDAMENTALS

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

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

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

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

Structure
1

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

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

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

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

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

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

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

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

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

10

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

11

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

12

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

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

PTV AG

Structure

II

PTV AG

Contents
1

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


1.1
1.2
1.3
1.4
1.5

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


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

1.6

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

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


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

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

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

2.2

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

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


2.2.1
2.2.2
2.2.3

PTV AG

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


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

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


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

III

Contents

2.2.4
2.2.5

2.3

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

2.4
2.5

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


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

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


3.1

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


3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.1.7

3.2

3.3

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

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


3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.2.6

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


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

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


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

IV

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

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


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

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


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

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


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

Contents

3.4

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


3.4.1
3.4.2
3.4.3

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


4.1

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


4.1.1
4.1.2
4.1.3

4.2
4.3
4.4

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


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

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


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

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


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

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


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

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


5.1
5.2
5.3
5.4

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


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

5.5

228
228
229
277

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


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

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


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

PTV AG

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


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

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


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

5.9
5.10

216
218
224
225

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


5.5.1
5.5.2
5.5.3
5.5.4

5.6
5.7
5.8

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


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

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


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

309
309
310
311
312
314

Contents

5.11

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


5.11.1
5.11.2
5.11.3
5.11.4

5.12

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


5.12.1
5.12.2
5.12.3
5.12.4
5.12.5

5.13

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


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

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

VI

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


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

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


5.16.1
5.16.2
5.16.3
5.16.4
5.16.5

5.17

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


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

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


5.15.1
5.15.2
5.15.3
5.15.4
5.15.5

5.16

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


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

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

5.15

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


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

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


5.13.1
5.13.2
5.13.3
5.13.4
5.13.5
5.13.6
5.13.7
5.13.8

5.14

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


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

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


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

PTV AG

Contents

5.18

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


5.18.1
5.18.2
5.18.3
5.18.4
5.18.5
5.18.6
5.18.7
5.18.8
5.18.9

5.19

389
390
393
397
406
408
410
412
418

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


5.19.1
5.19.2
5.19.3

5.20
5.21

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


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

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


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

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


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

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


6.1
6.2
6.3
6.4

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


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

6.5
6.6
6.7
6.8

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


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

453
454
456
459
465
470
471
474

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


6.10.1

PTV AG

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


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

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


6.9.1
6.9.2
6.9.3
6.9.4
6.9.5
6.9.6
6.9.7
6.9.8

6.10

437
446
447
447

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


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

6.9

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


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

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

VII

Contents

6.10.2
6.10.3
6.10.4
6.10.5
6.10.6
6.10.7
6.10.8

6.11
6.12

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


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

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


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

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


7.1

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


7.1.1
7.1.2

7.2
7.3
7.4

7.5

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


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

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


7.5.1
7.5.2
7.5.3
7.5.4

7.6

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


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

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


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

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


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

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


7.6.1
7.6.2
7.6.3
7.6.4
7.6.5
7.6.6
7.6.7
7.6.8

VIII

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


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

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


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

PTV AG

Contents

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


8.1

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


8.1.1
8.1.2
8.1.3

8.2

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


8.2.1
8.2.2

8.3

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


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

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


10.1
10.2

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


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

10.3
10.4
10.5

10.6

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


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

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

11

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


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

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


9.1
9.2
9.3
9.4

10

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


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

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


8.3.1
8.3.2

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


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

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

688
688
689
694

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

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


11.1

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


11.1.1
11.1.2
11.1.3
11.1.4
11.1.5

11.2

PTV AG

699
701
705
706
711

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

11.3

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


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

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


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

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

IX

Contents

12

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


12.1

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

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

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


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

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

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


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

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


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

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

PTV AG

Fundamentals of the program


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

PTV AG

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

Chapter 1: Fundamentals of the program

Transport model
Demand model

Network model

contains demand data:


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

contains supply data:


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

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

Results
Listings and statistics
Indicator matrices
Graphical analysis
Plots

(calculated attributes of network objects and routes)


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

Illustration 1: Visum network model and impact model

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

1.1

Network model the transport supply


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

PTV AG

Chapter 1.2: Transport demand model

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

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

Input attributes such as link length or link number.


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

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

1.2

Transport demand model


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

PTV AG

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

Chapter 1: Fundamentals of the program

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

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

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

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

PTV AG

Chapter 1.2: Transport demand model

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

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

Temporal distribution of travel demand


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

proportional time series of one demand matrix


as a distribution curve consisting of several demand matrices

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

PTV AG

Chapter 1: Fundamentals of the program

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

7:30

8:00

8:30

9:00

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

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

1.3

Impact models methods to calculate the impact of traffic


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

Impacts on the user of the transport system


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

Transport supply-side users


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

PTV AG

Chapter 1.4: Analysis of results

Transport supply-side operators


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

Models to calculate the impact of traffic


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

1.4

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


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

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

PTV AG

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

Chapter 1: Fundamentals of the program

1.5

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

Comparing and transferring networks


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

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


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

Version comparison and network merge


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

Version comparison with transfer of selected direct attributes


Version comparison with comparison network loaded in the background

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

Version comparison

Network merge (previously difference network)

Normal working is possible. For the relations,


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

Special mode serving mere evaluation purposes,


hardly editable, not savable

Simultaneous comparison of various variants


possible

Comparison with exactly one variant

PTV AG

Chapter 1.5: Comparing and transferring networks

Version comparison

Network merge (previously difference network)

New evaluation attributes/values of relations are


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

Evaluation attributes replace original attributes, i.e.


graphic parameters, filters etc. have to be adjusted

Evaluation attributes (beside value of original


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

Evaluation attributes: Value of original network,


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

According to the type of version comparison, either


attributes are selected or relations are built to all
objects

All attributes and network object types are


compared.

Updatable by pushing a button

Not updatable

Model transfer files


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

1.5.1

Comparing version files


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

PTV AG

Version comparison with transfer of attributes

Version comparison with comparison network


in the background

Attributes of the comparison network are


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

Via a relation to the comparison network, all


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

The direct attributes selected are adopted.

All direct and indirect attributes can be analyzed.

Filters are not regarded.

Filters in the opened network are also evaluated in


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

Updating means, that current attribute values of the


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

Updating means, that the path can optionally be


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

Chapter 1: Fundamentals of the program

Version comparison with transfer of attributes

Version comparison with comparison network


in the background

When you delete the version comparison, the


comparison network attributes are removed from
the opened network.

To prevent automatic comparison network loading


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

The values of the selected attributes of the opened


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

The attributes of the comparison network become


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

Use cases for version comparison


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

PTV AG

Chapter 1.5: Comparing and transferring networks

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

Version comparison with transfer of attributes


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

Short name English

Long name English

Value of network B

VolVehPrT,B(AP)

Volume PrT [Veh] B (AP)

Absolute difference A-B

VolVehPrT,-B(AP)

Volume PrT [Veh] - B (AP)

Absolute difference B-A

VolVehPrT,B-(AP)

Volume PrT [Veh] B - (AP)

Relative deviation regarding B (A-B)/B

VolVehPrT,-B%(AP)

Volume PrT [Veh] - B % (AP)

Relative deviation regarding A (B-A)/A

VolVehPrT,B-%(AP)

Volume PrT [Veh] B - % (AP)

Minimum of both attribute values

VolVehPrT,B,Min(AP)

Volume PrT [Veh] B Min (AP)

Maximum of both attribute values

VolVehPrT,B,Max(AP)

Volume PrT [Veh] B Max (AP)

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

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

PTV AG

11

Chapter 1: Fundamentals of the program

Illustration 3: Network of the original version

Illustration 4: Network of the version used for version comparison

12

PTV AG

Chapter 1.5: Comparing and transferring networks

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

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

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

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


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

PTV AG

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


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

13

Chapter 1: Fundamentals of the program

Version comparison with comparison network in the background


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

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

1.5.2

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

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

Use cases for network merge


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

14

PTV AG

Chapter 1.5: Comparing and transferring networks

Illustration 6: Network 1 used for merge network

Illustration 7: Network 2 used for merge network

The merge network


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

PTV AG

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


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

15

Chapter 1: Fundamentals of the program

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

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

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


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

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

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

16

PTV AG

Chapter 1.5: Comparing and transferring networks

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

Illustration 8: Merge network of network 1 and network 2

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

Characteristic: Analysis time intervals


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

1.5.3

Model transfer files


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

PTV AG

17

Chapter 1: Fundamentals of the program

Use cases for model transfer files


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

1.6

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

1.6.1

Visum saves all project files in a standard folder structure.


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

Keywords: project, modification, scenario


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

18

PTV AG

Chapter 1.6: Managing scenarios

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

PTV AG

19

Chapter 1: Fundamentals of the program

Scenario code

Meaning

Base version

M1

S0
B

M2

Null case

by-pass road only

speed limit only

BS

by-pass road + speed


limit

Table 2: Definition of scenarios based on modifications

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

Meaning

Base version

M1

M2

M3

S0

Null case

by-pass road only

speed limit only

BS

by-pass road + speed limit

S0_2020

Null case 2020

B_2020

by-pass road 2020 only

S_2020

speed limit 2020 only

BS_2020

by-pass road + speed limit


2020

Table 3: Extension of scenarios for a demand variant

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

1.6.2

Managing projects efficiently


A project is ideally carried out in the following steps:

20

Creating or selecting a base version


Defining modifications
Defining scenarios based on modifications

PTV AG

Chapter 1.6: Managing scenarios

Specifying the procedure sequence


Calculating scenarios
Comparing calculation results

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

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

1.6.2.1

Creating or selecting a base version

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

PTV AG

21

Chapter 1: Fundamentals of the program

1.6.2.2

Defining modifications

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

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

Provide each user with a copy of the base version.


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

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

22

PTV AG

Chapter 1.6: Managing scenarios

1.6.2.3

Defining scenarios based on modifications

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

1.6.2.4

Specifying the procedure sequence

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

1.6.2.5

Calculating scenarios

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

PTV AG

23

Chapter 1: Fundamentals of the program

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

1.6.2.6

Distributing scenario calculations across multiple computers

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

Requirements for distributed scenario calculation


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

24

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

PTV AG

Chapter 1.6: Managing scenarios

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

Setting up the compute node


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

Illustration 9: Configuration of the Scenario calculation server

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

PTV AG

25

Chapter 1: Fundamentals of the program

Execution of distributed scenario calculation


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

1.6.2.7

Analyzing and comparing calculation results

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

26

PTV AG

Chapter 1.6: Managing scenarios

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

PTV AG

27

Chapter 1: Fundamentals of the program

28

PTV AG

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

Subjects

2.1

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

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

Description

Transport system
(TSys)

The transport supply consists of several transport systems. Transport systems


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

Mode

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


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

Demand segment
(DSeg)

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

Node

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

Table 4: Basic network objects of a transport network

PTV AG

29

Chapter 2: Network model

Network object

Turn

Turn standard

Link
Link type

Zone

Connector

Main node

Main turn

Main zone

Territory

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

Table 4: Basic network objects of a transport network

30

PTV AG

Chapter 2.1: Network objects

Network object

Description

OD pair

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

Path

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

Valid day

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

Table 4: Basic network objects of a transport network

Network object

Description

Stop

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

Stop area

Stop point

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

Table 5: PuT network objects of a transport network

PTV AG

31

Chapter 2: Network model

Network object

Line

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

Line route

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

Time profile

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

Vehicle journey

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

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

System route

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

PuT operators

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

Vehicle combination

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

Table 5: PuT network objects of a transport network

32

PTV AG

Chapter 2.1: Network objects

Network object

Description

Vehicle unit

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

Block version

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

Block item type

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

Ticket type

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

Fare zone

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

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

Network object

Point of Interest (POI)


and POI category

Count location

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

Table 6: General network objects

PTV AG

33

Chapter 2: Network model

Network object

Description

Detector

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

Toll system

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

GIS object

Screenlines are a useful construction to calibrate an assignment model by


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

Screenline

Table 6: General network objects

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

2.1.1

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


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

Transport systems, modes and demand segments


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

Priv.TSys2
(e.g. Car)

HGV

Car

Publ.TSys1
(e.g. Bus)

Park&Ride
(Car, Bus, Tram)

Publ.TSys2
(e.g. Tram)

Publ.Transport
(Bus+Tram)

Transport systems

Modes

HGV

Carprivate

Carbusiness

P&R

Publ.Transp
Students

Publ.Transp.
Adults

Demand
segments

Matrix

Matrix

Matrix

Matrix

Matrix

Matrix

Demand
matrices

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

34

PTV AG

Chapter 2.1: Network objects

2.1.1.1

Transport systems

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

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


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

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

PTV AG

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

Chapter 2: Network model

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

Description

Example

PrT

Transport system for private transport


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

Car,
HGV

PuT

PuT with timetable


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

PuTAux

Public transport system without timetable or


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

PuTWalk

Transport system for


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

Footpath,
Escalator,
Lift

Table 7: PrT transport systems properties

2.1.1.2

Modes

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

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

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

2.1.1.3

Demand segments

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

36

PTV AG

Chapter 2.1: Network objects

Demand segments can be used for differentiation among

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

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

PrT
in car units (CarUnits)
PuT
in passenger units

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

Assignment of demand segments


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

Tribut procedure, Stochastic or Dynamic stochastic assignment


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

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

2.1.2

Nodes and turns


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

PTV AG

37

Chapter 2: Network model

2.1.2.1

Node

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

2.1.2.2

Turn

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

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

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

A list of permitted/not permitted transport systems


PrT capacity
PrT time penalty
Actual change of direction

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

The turn can be used when constructing the line route.

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

Prohibited turns

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

38

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

PTV AG

Chapter 2.1: Network objects

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

2.1.2.3

Turn types

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


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

2.1.2.4

Turn standards

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

the type of node, via which the turn runs


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

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

Right of way

++

from major flow into major flow

+-

from major flow into minor flow

-+

from minor flow into major flow

--

from minor flow into minor flow

Table 8: Flow hierarchy symbols

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

PTV AG

39

Chapter 2: Network model

* Attention: Time always in seconds


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

2.1.2.5

PrT capacity and PrT turn time

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

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

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


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

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

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

(1)

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

2.1.3

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

40

PTV AG

Chapter 2.1: Network objects

2.1.3.1

Link types

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

List of permitted transport systems on a link


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

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

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

PTV AG

41

Chapter 2: Network model

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

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

2.1.3.2

Permitted transport systems

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

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


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

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

42

PTV AG

Chapter 2.1: Network objects

Car
Car

HGV
HGV

Bus
Bus

Tram
Tram

PuT-Walk
PuT-Walk

Car
Car

HGV
HGV

Bus
Bus

Tram
Tram

PuT-Walk
PuT-Walk

Car
Car

HGV
HGV

Bus
Bus

Tram
Tram

PuT-Walk
PuT-Walk

Road with tram lines

Car
Car

HGV
HGV

Bus
Bus

Tram
Tram

PuT-Walk
PuT-Walk

Car
Car

HGV
HGV

Bus
Bus

Tram
Tram

PuT-Walk
PuT-Walk

One-way road without tram lines

Car
Car

HGV
HGV

Bus
Bus

Tram
Tram

PuT-Walk
PuT-Walk

Transfer walk link

Illustration 13: Examples for defining transport systems of a link

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

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

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

2.1.3.3

PrT capacity, PrT speed and PrT travel time

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

Input: Length L [m]


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

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

PTV AG

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


t0-TSys = L 3.6 / v0-TSys

43

Chapter 2: Network model

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


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

Input: Free flow travel time t0 [s]


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

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

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

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

Link
v0 = 130 km/h

130

100

Car

HGV

vmax (HGV) = 100 km/h


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

2.1.3.4

PuT run time

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

44

PTV AG

Chapter 2.1: Network objects

2.1.4

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

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

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

PTV AG

45

Chapter 2: Network model

2.1.5

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

To zone

100

100

Demand matrix value (1 X)


0.00

Skim matrix value (JRT)

100

200

2,000.00

38.00

100

201

200.00

12.00

0.00

100

202

0.00

32.00

200

100

2,000.00

38.00

200

200

0.00

0.00

200

201

5,000.00

16.00

200

202

2,000.00

13.00

201

100

200.00

12.00

201

200

5,000.00

16.00

201

201

0.00

0.00

201

202

0.00

20.00

202

100

0.00

32.00

202

200

2,000.00

13.00

202

201

0.00

20.00

202

202

0.00

0.00

Table 9: OD pairs in the example Example.ver

2.1.6

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

46

Origin connector from zone to node


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

PTV AG

Chapter 2.1: Network objects

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

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

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

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

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

2.1.6.1

Distribution of demand of a zone to the connectors

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

PTV AG

47

Chapter 2: Network model

Illustration 17: Possibilities for modeling connectors

2.1.7

Main nodes and main turns


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

2.1.7.1

Main node

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

48

PTV AG

Chapter 2.1: Network objects

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

Illustration 18: Intersection area with multiple nodes

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

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

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

PTV AG

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

49

Chapter 2: Network model

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

4
1
3

Illustration 19: Node and link types of main nodes

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

2.1.7.2

Main turns

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

50

PTV AG

Chapter 2.1: Network objects

Illustration 20: Main turns open to traffic

Illustration 21: Main turns not open to traffic

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

2.1.8

Main zones and main OD pairs


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

PTV AG

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

51

Chapter 2: Network model

Display of desire lines


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

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

2.1.9

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

2.1.10

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

Editing paths in PrT (PrT path object)


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

52

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

Chapter 2.1: Network objects

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

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

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

Total weight =

i = 1 ShareOfPathTarget

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

PTV AG

53

Chapter 2: Network model

2.1.11

Stop hierarchy: Stops, stop areas, stop points


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

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

Stop point
at link 1-2
after 50 m

Stop area

H
1

H
Stop

Illustration 22: The stop hierarchy

2.1.11.1 Stop points


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

54

PTV AG

Chapter 2.1: Network objects

Undirected
stop point on link

H
Directed
stop point on link

Stop point on node

Link stop points


Illustration 23: Possibilities of modeling stop points

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

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

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

2.1.11.2 Stop areas


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

PTV AG

55

Chapter 2: Network model

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

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

2.1.12

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

56

PTV AG

Chapter 2.1: Network objects

2.1.13

PuT vehicles: Vehicle units and vehicle combinations


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

2.1.14

The line hierarchy


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

PTV AG

57

Chapter 2: Network model

2.1.14.1 Network objects of the line hierarchy


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

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

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

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

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

58

PTV AG

Chapter 2.1: Network objects

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

Line route 1

Line route 2

M
S

important route point for line


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

PTV AG

59

Chapter 2: Network model

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

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

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

60

PTV AG

Chapter 2.1: Network objects

Line route 1

Time profile 1.1

SPoint

Stop

Time profile 1.2


Arr

Dep.

SPoint

Stop

0:00

Arr

Dep.

1:00

1:02

2:00

2:02

1:50

1:52

3:00

3:02

2:50

2:52

5:00

5:02

4:50

5:02

6:00

6:00

0:00

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

Vehicle journeys (=journeys)


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

PTV AG

61

Chapter 2: Network model

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

Vehicle journey sections (=journey sections)


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

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

This results in the following application possibilities for example.

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

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

62

Trip number

from -> to

Departure time

Valid day

Vehicle combination

991

NH

06:02 a.m. (daily)

Daily

Loco + 6 coaches

992

MH

05:10 a.m. (daily)

Daily

Loco + 6 coaches

993

MH

06:00 a.m. (daily)

Daily

Loco + 6 coaches

HS

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

Sat+Sun

Loco + 6 coaches

MN

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

1 additional coach

PTV AG

Chapter 2.1: Network objects

Line
Line route
Time profile

IC1

IC1

1.1

1.2

1.1

Trip number

991

992

Valid day

Daily

Daily

Vehicle combination

L+6C
-

M dep.

IC1

993
-

Mon-Fri

Sat+Sun

Mon-Fri

L+6C

L+6C

L+6C

1C

5:10

6:00

I arr.

07:00 a.m.

I dep.

07:02 a.m.

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

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

N arr.
N dep.

W arr.

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

W dep.

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

H arr.

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

H dep.

11:02 a.m.

S arr.

12:00 a.m.

Trip number 991 requires one vehicle journey section


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

2.1.14.2 Specifications of lengths and times


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

PTV AG

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

63

Chapter 2: Network model

Connection between lengths

Mulit-Edit Attribute: use Length DirDist

Link

Mulit-Edit Attribute: use Length Polygon

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

Standard

Line route items


Set lengths: uses the length of the link

To Length
Manual overwriting

Legend
Standard

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

Illustration 27: Lengths in Visum and their coherence

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

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

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

64

Transferring the standard values from the link run time


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

PTV AG

Chapter 2.1: Network objects

Allocation of run times


Link length
Link type-specific speed of the PuTSys
Standard

Link

Generating link run times from line run times

Link run time t-PuTSys

Standard values
Manual overwriting

Standard
Set times: from link run time

Time profile

Set times: from system route

run time

Set times: from link attribute


Set times: from time profile item attribute

Auto

Manual overwriting

Vehicle journey
Departure/ Arrival

Legend
Standard

Auto

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

Illustration 28: Assignment of run times in Visum

2.1.14.3 The term timetable in Visum


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

PTV AG

65

Chapter 2: Network model

2.1.14.4 Data consistency along the line hierarchy


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

2.1.14.5 Aggregation of line routes


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

Criteria for aggregating line routes


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

66

PTV AG

Chapter 2.1: Network objects

Line routes to be aggregated


A

Aggregated line routes


D

F
A

Violates criterion 2: The start of the path leg in


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

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


is not the end of either line route
Aggregation not possible

Violates criteria 2 and 3 Aggregation not possible

Illustration 29: Example of the aggregation of line routes

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

Line routes have to be assigned to the same line.


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

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

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

2.1.14.6 Coupling time profiles


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

PTV AG

67

Chapter 2: Network model

H1

L1-1

H4

H3

L1-2
L1-3

L1-1
H2

H1

H3

H2

H5

L1-2

H5

H4

H6

H3

L1-1

L1-1

H5

L1-2
L1-3
H1

H2

H4

H6

H1

H2

H3

H4

L1-2

Illustration 30: Examples: Coupling two and three line routes

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

Changes to the number of vehicle journeys


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

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

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

Changes to the temporal position of vehicle journeys


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

68

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


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

PTV AG

Chapter 2.1: Network objects

Coupling when calculating the PuT operating indicators


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

Service-km of the line route


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

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

40 km
30 min

50 km
30 min

40 km
30 min

H1

H4

L1-1
H3

H2
L1-2

H5

H6

40 km
30 min

50 km
30 min

40 km
40 min

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

PTV AG

69

Chapter 2: Network model

Number of trips

10 trips

Empty time

10 min/trip

Kilometer costs

1 euro/km

Hourly costs

60 euros/h

Track price

1 euro/km

Seats

100 seats/vehicle combination

Table 11: Input data for the calculation example


Not coupled

Not coupled

Coupled

Coupled

L1-1

L1-2

L1-1

L1-2

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

1,300 km

1,300 km

1,050 km

1,050 km

13,000 km

13,000 km

13,000 km

13,000 km

900 min

1,000 min

750 min

850 min

1,000 min

1,100 min

850 min

950 min

Cost

1,300 EUR

1,300 EUR

1,050 EUR

1,050 EUR

Cost

1,000 EUR

1,100 EUR

850 EUR

950 EUR

Track costs

1,300 EUR

1,300 EUR

1,050 EUR

1,050 EUR

Total cost

3,500 EUR

3,600 EUR

2,950 EUR

3,050 EUR

10

10

10

10

Num Vehicle
journeys

Table 12: Calculation of indicators for the line route


Link
ServiceKm
Num Vehicle
journeys

H2-H3

H3-H4

H2-H3

H3-H4

1,000 km

400 km

500 km

400 km

20

10

10

10

Table 13: Calculation of indicators for the links

2.1.15

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

70

Editing the shape of a line route with system routes


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

PTV AG

Chapter 2.1: Network objects

Editing the shape of a line route with system routes


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

Setting travel times of existing line routes and time profiles


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

Both profile points are located at stop points.


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

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

PTV AG

71

Chapter 2: Network model

2.1.16

Points of Interest (POI)


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

Illustration 32: Reachability analyses for secondary schools

72

PTV AG

Chapter 2.1: Network objects

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

Parking and Park&Ride facilities


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

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

Illustration 33: Allocating POIs to links

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

PTV AG

73

Chapter 2: Network model

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

2.1.17

Count locations and detectors


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

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

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

74

PTV AG

Chapter 2.1: Network objects

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

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

2.1.18

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

PTV AG

75

Chapter 2: Network model

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

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

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

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

2.1.19

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

76

PTV AG

Chapter 2.1: Network objects

2.1.20

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

Number of links which intersect the screenline.


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

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

Illustration 36: Summation and average calculations with screenlines

PTV AG

77

Chapter 2: Network model

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

Illustration 37: Calculation of the urban traffic volume with screenlines

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


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

2.1.21

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

78

PTV AG

Chapter 2.1: Network objects

Element

Description

Geometry

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

Leg

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

Lanes

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

Lane turn

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

Signal control

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

Stage

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

Signal group

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


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

Crosswalk

Crosswalks serve to describe the pedestrian conditions at nodes and main


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

Detector

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


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

Table 14: Network objects of the junction model

2.1.21.1 Link orientations


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

PTV AG

79

Chapter 2: Network model

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

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

Calculating the performance at a node


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

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

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

80

PTV AG

Chapter 2.1: Network objects

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

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

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

PTV AG

81

Chapter 2: Network model

Leg templates and geometry templates


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

2.1.21.3 Signal control


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

82

PTV AG

Chapter 2.1: Network objects

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

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

PTV AG

83

Chapter 2: Network model

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

2.1.22

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

2.2

Spatial and temporal correlations in Visum


In Visum, the following can be specified:

2.2.1

Calendar
Valid days
Time series
Analysis time slots

Calendar and valid days


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

2.2.1.1

Calendar

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

84

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

PTV AG

Chapter 2.2: Spatial and temporal correlations in Visum

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

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

Dynamic assignment in PrT


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

2.2.1.2

Valid days

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

PTV AG

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

85

Chapter 2: Network model

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

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

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


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

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

2.2.2

Time reference of the demand (time series)


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

86

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

PTV AG

Chapter 2.2: Spatial and temporal correlations in Visum

Illustration 38: Time series by percentage

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

Illustration 39: Time series of matrix numbers

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

PTV AG

87

Chapter 2: Network model

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

2.2.3

Time reference of the volumes: Analysis time slots and projection


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

88

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

PTV AG

Chapter 2.2: Spatial and temporal correlations in Visum

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

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

Calendar period CP
Day n

Day 1
Analysis period AP in CP
AP

Analysis time interval AI in AP

AI

Assignment time interval ATI in AP

ATI

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

Illustration 40: The relationship between the different analysis time slots

PTV AG

89

Chapter 2: Network model

Example of projection factors


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

Projection factor AP

Projection factor AH

Standard working day

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

Saturday

52

Sunday

52

Table 15: Deriving projection factors for AP and AH

Example of the interaction of analysis time intervals and time series


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

DSeg
DSeg
start day start
time

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

Ex. 1 Weekly
calendar

Mon 06:3007:30 a.m.

Mon-Mon Mon

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

02:00:00

No

Ex. 2 Weekly
calendar

Mon 06:3007:30 a.m.

Mon-Mon Mon

05:30:00 00:00:00

02:00:00

Yes

Ex. 3 Weekly
calendar

Mon 06:3007:30 a.m.

Mon-Mon Mon

00:00:00 05:30:00

07:30:00
a.m.

Yes

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

90

PTV AG

Chapter 2.2: Spatial and temporal correlations in Visum

Time series of the


demand segment

Mo

Tu

Calendar period CP
1:00

3:00
6:30

Analysis period AP in CP

7:30

AP

Assignment interval AI in AP

AI

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

Time series of the


demand segment

Mo

Tu

Calendar period CP
5:30

Analysis period AP in CP

Assignment interval AI in AP

6:30

7:30

AP

AI

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

PTV AG

91

Chapter 2: Network model

Share of the demand


that is assigned
DSeg
Start time
Mo. 00:00

Time series of the


demand segment

Mo

Tu

Calendar period CP
5:30

Analysis period AP in CP

Assignment interval AI in AP

6:30

7:30

AP

AI

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

2.2.4

Temporal and spatial differentiation of calculation results


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

2.2.4.1

Temporal distinction with analysis time intervals

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

92

PTV AG

Chapter 2.2: Spatial and temporal correlations in Visum

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

2.2.4.2

Spatial distinction with territories

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

2.2.5

Adjustment of the capacities to the demand values


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

PTV AG

93

Chapter 2: Network model

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

2.3

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

Direct attributes
Indirect attributes

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

2.3.1

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

Input attributes (e.g. stop number) and


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

Each Visum attribute is described as follows:

by a name (for example Number)


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

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

94

PTV AG

Chapter 2.3: Attributes

Attribute

Input attribute

Calculated attribute

Number

TSysSet

Capacity PrT

Number of lanes

t0-PrTSys

tCur-PrTSys

Capacity PrT [Veh]

Saturation PuT seats

Passenger kilometers

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

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

2.3.2

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

PTV AG

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

95

Chapter 2: Network model

Selection of the indirect attribute Zone\Number of


connectors in the attribute selection window

The indirect attribute is displayed in the list next to


the direct attributes of the connector.

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

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

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

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

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

96

PTV AG

Chapter 2.3: Attributes

Count and CountActive


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

Selection of the indirect attribute Count:Stop


areas in the attribute selection window for stops

The indirect attribute is displayed in the list next to


the direct attributes of the stop.

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

Min and MinActive


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

Selection of the indirect attribute Min:Stop


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

The indirect attribute is displayed in the list next to


the direct attributes of the stop area.

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

PTV AG

97

Chapter 2: Network model

Max and MaxActive


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

Selection of the indirect attribute Max:Stop


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

The indirect attribute is displayed in the list next to


the direct attributes of the stop area.

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

Sum and SumActive


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

Selection of the indirect attribute Sum:Stop


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

The indirect attribute is displayed in the list next to


the direct attributes of the stop area.

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

98

PTV AG

Chapter 2.3: Attributes

Avg and AvgActive


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

Selection of the indirect attribute Avg:Stop


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

The indirect attribute is displayed in the list next to the


direct attributes of the stop area.

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

PTV AG

Concatenate and ConcatenateActive


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

99

Chapter 2: Network model

Selection of the indirect attribute


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

The indirect attribute is displayed in the list next to the


direct attributes of the stop area.

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

100

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

PTV AG

Chapter 2.3: Attributes

Selection of the indirect attribute


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

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

2.3.3

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

PTV AG

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

101

Chapter 2: Network model

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

102

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

PTV AG

Chapter 2.3: Attributes

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

Different categories of vehicle journeys


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

Line name

Costs [CU]

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

001

13,012.86

22.94

567.06

002

22,797.80

36.02

632.83

003

13,390.06

14.60

916.71

004

10,428.43

19.99

521.58

005

10,109.21

17.87

565.65

006

6,833.93

23.03

296.65

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

PTV AG

103

Chapter 2: Network model

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

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

2.3.3.1

Formula attributes

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

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

104

PTV AG

Chapter 2.3: Attributes

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

Example

2.3.4

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


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

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

Links
Turns
Main turns
Nodes
Main nodes

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

Time-varying attribute

Links

Out capacity PrT


Capacity PrT

Dynamic Stochastic Assignment

DUE
X

Toll-PrTSys

X
X

v0 PrT

TSysSet

AddValue 1-3
AddValue-TSys
Turns

Capacity PrT

ICA final capacity


t0 PrT

TSysSet

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

PTV AG

105

Chapter 2: Network model

AddValue 1-3
Main turns

Capacity PrT

t0 PrT

TSysSet

AddValue 1-3
Nodes

Capacity PrT

t0 PrT

AddValue 1-3
Main nodes

Capacity PrT

t0 PrT

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

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

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

106

PTV AG

Chapter 2.4: Subnetwork generator

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

2.4

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

PTV AG

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

107

Chapter 2: Network model

All existing toll systems with at least one active link


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

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

108

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

PTV AG

Chapter 2.4: Subnetwork generator

* when activating option Include the demand model in the subnetwork

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

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

PrT demand matrices


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

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

PTV AG

109

Chapter 2: Network model

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

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

Zone

12

External zone

Path leg on active line route

Node

Walk link (via at least one passive link)

Stop point

Pathleg on passive line route


Stop point matrix (regarding path legs)

12

13

14

15

16

17

18

Stop point matrix:


1

12
13
14
15
16
17
18

12 13 14 15 16 17 18
50
50
50
50

Stop point matrix (regarding paths)

12

14

15

18

8
Stop point matrix:
12
14
15
18

12 14 15 18
50
50

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

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

110

PTV AG

Chapter 2.5: The surface data model in Visum

2.5

The surface data model in Visum


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

2.5.1

Tables in the surface model


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

Point
Edge
Edge item
Face
Face item
Surface
Surface item

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

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

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

PTV AG

111

Chapter 2: Network model

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

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

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

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

112

PTV AG

Chapter 2.5: The surface data model in Visum

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

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

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

PTV AG

113

Chapter 2: Network model

2.5.2

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

c lo c

kwi

lo c k

w is e =
p o s it
iv

se =
neg

a t iv

anti-clockwise
= positive

Illustration 47: Positive and negative surfaces

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

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


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

Normalized shape of the surface

Two separate faces

OK the surface remains unchanged

Table 38: Examples of the normalization of surfaces

114

PTV AG

Chapter 2.5: The surface data model in Visum

Specified surface

Normalized shape of the surface

Two overlapping faces

not OK both faces have been merged

A face with a hole

OK the surface remains unchanged

A face with a hole which intersects the


boundary of the surface

not OK the hole is omitted and the face


adjusted

A face with an intersecting boundary

not OK the negative part is deleted

Table 38: Examples of the normalization of surfaces

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

PTV AG

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


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

115

Chapter 2: Network model

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

When does the program normalize?


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

How accurate is the normalization (for experts)?


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

116

PTV AG

Chapter 2.5: The surface data model in Visum

2.5.3

Sharing points between surfaces


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

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

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

PTV AG

117

Chapter 2: Network model

118

PTV AG

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

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


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

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

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


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

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

Subjects

3.1

Demand objects
Demand modeling procedures
Displaying and editing matrices
Matrix correction

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

PTV AG

Matrices

119

Chapter 3: Demand model

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

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

3.1.1

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

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

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

3.1.2

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

120

PTV AG

Chapter 3.1: Demand objects

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

3.1.3

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

3.1.4

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

Demand model structure


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

PTV AG

Attribute

Description

Code (Key)

Code (any string), for example EVA-P

Name

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

Type

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

Mode codes

Abbreviation of the modes of the demand model

121

Chapter 3: Demand model

3.1.5

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

E+c

Employees without car

E-c

Not-employed with car available

NE+c

Not-employed without car

NE-c

Apprentices

Appren

Students 18 yrs and older

Stud

Pupils from secondary school

SPup

Primary school pupils

PPup

Children under six

Child

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


Attribute

Description

Code (Key)

Code (any string), for example Stud

Name

Name of person group, for example students

DemandModelCode

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

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

3.1.6

Activities, activity pairs, activity chains


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

122

Work

Shopping

Education: vocational school

Education: university

Education: secondary school.

Education: primary school

Recreation

PTV AG

Chapter 3.1: Demand objects

Home

The demand object activity is described by the following attributes:


Attribute

Description

Code (Key)

Code (any string), for example W

Name

Name of the activity, for example housing

IsHomeActivity

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

DemandModelCode

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

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

Description

Code (Key)

Code (any string), for example HW

Name

Name of the activity pair, for example home - work

DemandModelCode

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

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

Description

OrigActivityCode

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

DestActivityCode

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

OD type

Direction of the activity pair in terms of the home activity


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

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

PTV AG

123

Chapter 3: Demand model

Attribute

Description

Code (Key)

Code (any string), for example HWH

Name

Name of the activity chain, for example home work home

ActivityCodes

Comma-separated list of activity codes

DemandModelCode

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

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

3.1.7

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

OrigActivity n

n DestActivity

Activity Pair
e.g. HW
n
m

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

Activity Chain
e.g. HW-WH

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

n
n

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

Illustration 48: Correlations between different demand objects

The demand object demand stratum has the following attributes.

124

Attribute

Description

Code (Key)

Code (any string), for example HWH Stud

ActChainCode

Activity chain code (optional)

DemandGroupCodes

Person group codes (optional)

Name

Name of demand stratum, for example student-shopping or


employee+car home-shopping-home

PTV AG

Chapter 3.2: Demand modeling procedures

Attribute

Description

DemandModelCode

Abbreviation of the demand model, for the respective demand


stratum, for example DEFAULT

DistribMatrixNumber

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


this demand stratum is stored (optional)

DemandTimeSeriesNumber

Number of demand time series for temporal distribution of demand


(optional).

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

Description

Origin Structural Property Codes Origin of the structural property codes

3.2

Destination Structural Property


Codes

Destination of the structural properties codes

Balancing

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


balancing takes place

Quantity as potential

This Boolean attribute describes whether the productions or


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

Marginal totals type origin


Marginal totals type destination

Type of marginal totals of the constraint on origin or destination


side

Marginal totals min factor origin


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

This Boolean attribute describes, whether the lower or upper limit


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

Constraints min factor origin


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

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

Demand modeling procedures


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

PTV AG

125

Chapter 3: Demand model

Standard 4-step model


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

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

3.2.1

Estimate gravitation parameters (KALIBRI)


Gravity model calculation
Iteration

Standard 4-step model


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

126

PTV AG

Chapter 3.2: Demand modeling procedures

Per demand stratum

production
rates

zone
attributes
(inhabitants,
jobs)

Trip generation
skim
matrix

utility
function

production
& attraction
(per zone)

Trip distribution
skim matrix
per mode

utility
function

demand
matrix

Mode choice

Per
demand
segment

demand
matrix

Assignment

demand
matrix

demand
matrix

Assignment

demand
matrix

Assignment

Illustration 49: Integrated 4-step demand model in Visum

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


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

PTV AG

127

Chapter 3: Demand model

Illustration 50: Extended 4-step model

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

3.2.1.1

Trip generation

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

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

128

PTV AG

Chapter 3.2: Demand modeling procedures

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

Qi = Z j
i

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

3.2.1.2

Trip distribution

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

PTV AG

129

Chapter 3: Demand model

3.2.1.3

Mode choice

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

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

cijmg

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

p ijm =

c U ijm

c U ijk

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

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

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

3.2.1.4

Nested Mode Choice

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

130

PTV AG

Chapter 3.2: Demand modeling procedures

Illustration 51: Modeling through decision tree

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

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

This leads to

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

3.2.1.5

Time-of-day choice

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

PTV AG

131

Chapter 3: Demand model

3.2.2

EVA model for passenger demand


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

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

3.2.2.1

EVA data model

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

Activities and activity pairs


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

Attribute and range of


values

Meaning

Activity

IsHomeActivity
bool (0,1)

The value of 1 specifies the activity representing the road


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

Activity pairs

OD type
{1, 2, 3}

1 = Origin activity is home activity


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

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

132

PTV AG

Chapter 3.2: Demand modeling procedures

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

PTV AG

Attribute

Meaning and range of values

Origin Structural
Property Codes

Parameters specifying the structural potential of the demand stratum on the


origin side.
Range: set of structural properties

Destination Structural
Property Codes

As above for destination side


Range: set of structural properties

Balancing
(Balancing on the user
interface)

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

Quantity as potential

1 = productions or attractions also define the structural potential


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

Marginal totals type


origin
(Constraint Orig. on the
user interface)

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


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

Marginal totals type


destination
(Constraint Dest on the
user interface)

As above for destination side


Range: {hard, weak, elastic, open}

Marginal totals min


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

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


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

Constraints max factor


origin constant
(CF OMax constant on
the user interface)

As above for the upper limit on origin side


Range: bool (0, 1)

133

Chapter 3: Demand model

Attribute

Meaning and range of values

Constraints min factor


destination constant
(CF DMin constant on
the user interface)

As above for the lower limit on destination side


Range: bool (0, 1)

Constraints max factor


destination constant
(CF DMax constant on
the user interface)

As above for the upper limit on destination side


Range: bool (0, 1)

Constraints min factor


origin
(CF OMin on the user
interface)

Factor for the lower limit of the productions if


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

Constraints max factor


origin
(CF OMax on the user
interface)

As above for the upper limit on origin side


Range: floating point number 0

Constraints min factor


destination
(CF DMin on the user
interface)

As above for the lower limit on destination side


Range: floating point number 0

Constraints max factor


destination
(CF DMax on the user
interface)

As above for the upper limit on destination side


Range: floating point number 0

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

134

Attribute

Subattribute

Meaning and range of values

Balance factor
Productions

Demand stratum

Weighting of demand stratum productions


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

Balance factor
Attractions

Demand stratum

Weighting of demand stratum attractions


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

Constraints min factor


origin

Demand stratum

Factor for the lower limit of the productions if


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

Constraints max factor


origin

Demand stratum

As above for the upper limit on origin side


Range: floating point number 0

Constraints min factor


destination

Demand stratum

As above for the lower limit on destination side


Range: floating point number 0

PTV AG

Chapter 3.2: Demand modeling procedures

Attribute

Subattribute

Meaning and range of values

Constraints max factor


destination

Demand stratum

As above for the upper limit on destination side


Range: floating point number 0

Number of persons

Person group

Number of inhabitants of the person group in zone


Range: integer 0

Structural property
value

Structural
property

Value taken by the structural property in zone


Range: floating point number 0

Mobility rate

Demand stratum
Person group

Specific traffic demand of a person group for the demand


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

Production rate

Demand stratum
Structural
property

Production rate of structural property for the demand


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

Attraction rate

Demand stratum
Structural
property

As above for destination side


Range: floating point number 0

Study area factor home

Demand stratum
Person group

Remaining share of home trips of the person group for


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

Study area factor origin

Demand stratum
Structural
property

Effective share of the structural property for the demand


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

Study area factor


destination

Demand stratum
Structural
property

As above for destination side


Range: floating point number 0

3.2.2.2

EVA trip generation

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

PTV AG

135

Chapter 3: Demand model

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

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

H
W

WH

CH

SH

FH

PH

RH

OH

HW

HC

HS

HF

HP

HR

HO
WO

OW

OO

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

136

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

HW

Employees

HC

Young children

HS

Pupils, apprentices, students

HF

Employees

HP

Inhabitants

HR

Inhabitants

HO

Inhabitants

WO

Jobs

PTV AG

Chapter 3.2: Demand modeling procedures

Demand stratum

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

WH

Jobs

CH

Jobs / capacity

SH

Jobs / capacity

FH

Jobs

PH

Jobs / sales floor

RH

Jobs / capacity

OH

Other jobs

OW

Other jobs

OO

Other jobs

DStr

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

HW

Jobs

HC

Jobs / capacity

HS

Jobs / capacity

HF

Jobs

HP

Jobs / sales floor

HR

Jobs / capacity

HO

Other jobs

WO

Other jobs

WH

Employees

CH

Young children

SH

Pupils, apprentices, students

FH

Employees

PH

Inhabitants

RH

Inhabitants

OH

Inhabitants

OW

Jobs

OO

Other jobs

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

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

PTV AG

137

Chapter 3: Demand model

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

Number of trips in DStr by persons of group p


.
Number of persons of person group p

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

138

PTV AG

Chapter 3.2: Demand modeling procedures

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

Qicmax and Zjcmax of these demands are calculated.


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

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


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

The calculation specifications can be taken from table 41, table 42 and table 43. For the types
1 and 2 calculation starts with the home trips (of number of persons, mobility rate, study area
factor) which independently from the travel direction always occur in the origin zone. For type
1 the number of trips corresponds exactly to the production, for type 2 to the attraction of the
respective zone. For type 1 the total production (of all zones) is distributed onto the destination
zones, in proportion to their potentials (taken from structural properties, production rates and
study area factors). Type 2 is treated equally. The total attraction is distributed proportionally to
the potentials onto the origin zones. For type 3 total volume is equally calculated on the basis
of the total home trips. However, the sizes of the road users origin zones are relevant, which
do not have to correspond with origin or destination of the trip. Proportionally to the potential
the total volume is then distributed onto the origin zones on the one hand and onto the
destination zones on the other hand.
The productions and/or attractions so calculated can have various meanings.

Hard constraints

Traffic demand solely results from the spatial structure and has to be fully exhausted by the
trips calculated in the model.
Example: if the number of employed inhabitants and jobs per zone is known, hard
constraints will be applicable to the demand stratum Home Work (HW), since every
employed person necessarily has to commute to work and each job has to be destination
of commutation.

Weak constraints

Traffic demand does not only depend on the spatial structure but also on the convenience
of the location and the resulting competitive conditions. In these cases traffic demands
resulting from trip generation are like upper limits. With Trip distribution and Mode choice it
turns out to which extent the limits will be exhausted by the actually determined origin and/
or destination traffic.
The structural potential of the destination zone for the demand stratum Home Shopping
(HP) is usually calculated based on the structural property of sales floor and a production
rate for example. It is conceivable that there may be overabundance of sales floor so that
the shopping facilities are not used to their full potential. Therefore, the attraction calculated
by trip generation from the potential only constitutes an upper limit for real destination
traffic. Therefore, the constraint is hard on the destination side, whereas weak on the origin
side, because each road user has to shop (somewhere).

PTV AG

139

Chapter 3: Demand model

Elastic constraints

Elastic constraints are a generalization of weak constraints. Additionally to upper limits


lower limits are equally known, for the demand stratum Home - Shopping (HP), for
example, from sales statistics. In this case, the structural potential of the sales floor
determines an interval for the attraction of the respective zone.

Open constraints

The potential of the structural properties merely represents the attractiveness of the zone
as an origin or destination of a demand stratum. Production or attraction, however, are not
linked to any constraint.
The attractiveness of some destinations in recreational traffic can even be measured by
means of their attributes if capacity impacts do not play a role. For example, the structural
potential of a nearby recreational area can be determined by its forest. During trip
distribution this attractiveness is to impact as potential of the destination zone, but no
constraints are linked herewith because there is neither a minimum number of persons
seeking recreation nor do visitors go to other places, because the "capacity" of the forest is
fully exhausted.
In table 41, table 42 and table 43 the calculation formulas are listed up separately for the cases
for which they differ.
Step 1

Home trips H

H epc = MR epc BP ep u epc


H ec = MR epc BP ep u epc
pP

Step 2

Production Q, Qmax

Q ic = H ic
Step 3

Total volume V

Vc =
fc =

Q ic

i =1

Vc

ERsc SGs vsc


=1 sS
Table 41: Trip generation in EVA model: OD type 1

140

PTV AG

Chapter 3.2: Demand modeling procedures

Step 4

Attraction Z, Zmax

ER jsc SG js v jsc
sS
max
b ) Z jc Z max
jc = ER jsc SG js v jsc
sS
jc = ER max
jc Z jc Z jc Z jc
c )Z
jsc SG js v jsc ; Z jc Z
sS
d ) Z pot
jc = ER jsc SG js v jsc
sS
a ) Z jc = f c

Table 41: Trip generation in EVA model: OD type 1

Step 1

Home trips H

H epc = MR epc BP ep u epc


H ec = MR epc BP ep u epc
pP

Step 2

Attraction Z, Zmax

Z jc = H jc
Step 3

Total volume V

Vc =
fc =

Z jc

j =1

Vc

ERsc SGs vsc


=1 sS
Step 4

Production Q, Qmax

ERisc SGis visc


sS
max
max SG v
b )Q Q
= ERisc
is isc
ic
ic
sS
max SG v ; Q
= ERisc

c )Q
is isc ic Qic Qic Qic Q
ic
ic
sS
pot
d )Q
= ERisc SGis visc
ic
sS
a ) Q = fc
ic

Table 42: Trip generation in EVA model: OD type 2

PTV AG

141

Chapter 3: Demand model

Step 1

Home trips H

H epc = MR epc BP ep u epc


H ec = MR epc BP ep u epc
pP

Step 2

Total volume V

Vc =
Step 3

H ec

e =1

Production Q, Qmax

ERisc SGis visc


sS
Qic =
Vc
ERsc SGs vsc
sS
Attraction Z, Zmax

ER jsc SG js v jsc

Z jc =

sS

ERsc SGs vsc

Vc

sS

Table 43: Trip generation in EVA model: OD type 3

142

e
i
j
s
p
c
m
MRepc

Index of a zone producing trips (origin zone)

ERisc

Production rate of structural property s per time interval

BPep

Number of persons per person group p

SG
uepc

Structural property

visc

Structural property factor effective for study area-internal traffic

Hepc

Home trips (expected value) of person group p

Hec

Home trips (expected value) total

Qic

Production (expected value)

Zjc

Attraction (expected value)

Index of a zone being origin of trips


Index of a zone being destination of trips
Index of a structural property
Index of a person group
Index of a demand stratum
Number of zones in study area
Mobility rate of person group p per time interval

Factor of trips realized study area-internally

PTV AG

Chapter 3.2: Demand modeling procedures

Qicmax

Maximum possible production

Zjcmax

Maximum possible attraction


Factor for upper or lower limit of production

Q ,Qic
ic

Factor for upper or lower limit of attraction

Z jc , Z jc

Qicpot

Potential for origin traffic

Zjcpot

Potential for destination traffic

Vc

Total volume (expected value)

fc

Factor, which takes the compliance of the total constraint

V =

Qi
i

Zj
j

for the

calculation of the zones traffic volume into consideration

Qic*,

Zjc

Ancillary parameters for balancing (see below)

When analyzing the passenger demand flows it turns out that certain activity chains dominate
in the course of a day. So, for example, the chain of H W - P H occurs more often than the
chain of H P W H. With this, imbalances in the respective demand stratum pairs arise (for
example HW compared to WH) that are expressed in mobility or production rates.
Consequently, when calculating the total production of a certain zone i across all demand
strata, this sum does generally not correspond to the total attraction. This, however, should be
the case for a period considered closed with regard to traffic. Hence, in the EVA model, the
production or attraction of a selected ca demand stratum of the type 3 (mostly Others Others,
OO) is modified, so that the total production equals the total attraction across all demand
strata. This procedure is called balancing (see "EVA trip distribution and mode choice" on
page 152).
Balancing can either be performed after trip generation or trip distribution and mode choice. It
takes place after trip generation if the following conditions are fulfilled.

All constraints (except those of demand stratum ca) are hard.

The total volume in ca is higher than the difference between production and attraction that
needs to be balanced.
All modes are interchangeable.

Balancing after trip generation takes place in three steps.


1. Calculation of total production and total attraction for all demand strata except ca.

Q*i =

Qic Z *i = Z ic
c ca ;
c ca

2. Calculation of the demand to be compensated of all zones i.

Q*i = max{ 0 , Z *i Q*i } ; Z *i = max{ 0 , Q*i Z *i }

PTV AG

143

Chapter 3: Demand model

~
~
3. Correction of traffic volume in ca, whereby Qica and Zica are "preliminary" values taken
from the formulas in table 41, table 42 and table 43.
*
*
1
1 ------Q ic = Q

Q l + Z i
ic a
V c l

a
a

1
*
*
Z ic = Z ica 1 ------- Z l + Q i
Vc

a
l
a

If there are non-interchangeable modes, you need to perform the balancing procedure for each
of them individually. Then you perform a single balancing procedure for the sum of all
interchangeable modes. This, however, is only possible during distribution and mode choice.
The following example will illustrate the method. For simplification it is limited to five demand
strata covering all origin-destination types.
Activity
No.

Code

OD type

Person group

Origin

Destination

Origin zone

HW

Home

Work

Employees

HO

Home

Others

Inhabitants

WH

Work

Home

Employees

OH

Others

Home

Inhabitants

OO

Others

Others

Inhabitants

Relevant structural potential


No.

Origin zone

Destination zone

Code
HW

OD type
1

Like home

Jobs

HO

Like home

Jobs in tertiary sector and


inhabitants

WH

Jobs

Like home

OH

Jobs in tertiary sector and


inhabitants

Like home

OO

Jobs in tertiary sector and


inhabitants

Jobs in tertiary sector and


inhabitants

The model covers 18 zones, 10 of which belong to the actual study area (type 1) and 8 zones
form a cordon around them (type 2). The zones of type 1 feature study area factors of 1.0,
those of type 2 of 0.9. The relevant zone attributes are set as follows.
Zone

144

Type

Inhabitants

Employees

Jobs

Jobs tertiary

7,000

3,000

2,000

1,100

10,500

5,500

7,000

4,500

7,000

3,000

2,000

1,300

5,000

2,000

1,700

1,000

PTV AG

Chapter 3.2: Demand modeling procedures

Zone

Type

Inhabitants

3,000

Employees

Jobs

2,000

900

1,600

1,000

500

200

2,000

1,200

1,200

Jobs tertiary
2,500

1,600

5,000

2,000

1,000

600

7,000

3,100

2,500

1,400

10

5,000

2,000

1,500

1,000

11

3,500

1,200

1,000

600

12

3,000

1,100

1,000

600

13

2,500

1,000

1,000

600

14

1,500

700

500

100

15

1,500

600

500

100

16

2,000

900

1,000

600

17

2,000

800

500

300

18

2,000

800

500

300

Depending on demand stratum and zone type the following mobility rates are applicable (trips
per person in relevant person group).
Zone type

HW

HO

WH

OH

OO

0.7800

0.9000

0.6200

0.9000

0.6000

0.8100

0.9000

0.6400

0.9000

0.6000

The production rates of the structural properties equally depend on demand stratum and zone
type.
Demand stratum

Structural property

HW
HO

OO

PTV AG

Zone type 2

1.00

1.00

Inhabitants

0.50

0.50

Jobs in tertiary sector

0.50

0.50

WH
OH

Zone type 1

1.00

1.00

Inhabitants

0.50

0.50

Jobs in tertiary sector

0.50

0.50

Inhabitants

0.50

0.50

Jobs in tertiary sector

0.50

0.50

145

Chapter 3: Demand model

All demand strata feature hard constraints. This results in the productions and attractions of the
demand strata displayed in the following table, from the formulas in table 41, table 42 and
table 43. For clarification the respective step of the calculation process is indicated on top of
each column.

H = Home trips
Q = Production
Z = Attraction
QP = Structural potential origin
ZP = Structural potential destination

Demand stratum

HW

Person groups or structural


property
Calculation step

Origin
Like home

Jobs

Destination

Zone

Zone Type

ZP

2,340

2,340

2,000

1,578

4,290

4,290

7,000

5,523

2,340

2,340

2,000

1,578

1,560

1,560

1,700

1,341

936

936

2,500

1,972

702

702

1,600

1,262

156

156

2,000

1,578

1,560

1,560

1,000

789

2,418

2,418

2,500

1,972

10

1,560

1,560

1,500

1,183

11

875

875

900

710

12

802

802

900

710

13

729

729

900

710

14

510

510

450

355

15

437

437

450

355

16

656

656

900

710

17

583

583

450

355

18

Total

146

Home
Employee
s

583

583

450

355

23,038

23,038

29,200

23,038

PTV AG

Chapter 3.2: Demand modeling procedures

Demand stratum

HO

Person groups or
structural property
Calculation step

Home

Origin

Inhab.

Like
home

Destinati
on
Jobs in tertiary sector and inhabitants

3.1

3.2

Zone

Zone Type

ZP Inh.

ZP Jobs
tert

ZP Total

6,300

6,300

3,500

550

4,050

5,796

9,450

9,450

5,250

2,250

7,500

10,733

6,300

6,300

3,500

650

4,150

5,939

4,500

4,500

2,500

500

3,000

4,293

2,700

2,700

1,500

800

2,300

3,292

1,800

1,800

1,000

500

1,500

2,147

450

450

250

600

850

1,216

4,500

4,500

2,500

300

2,800

4,007

6,300

6,300

3,500

700

4,200

6,011

10

4,500

4,500

2,500

500

3,000

4,293

11

2,835

2,835

1,575

270

1,845

2,640

12

2,430

2,430

1,350

270

1,620

2,318

13

2,025

2,025

1,125

270

1,395

1,996

14

1,215

1,251

675

45

720

1,030

15

1,215

1,251

675

45

720

1,030

16

1,620

1,620

900

270

1,170

1,674

17

1,620

1,620

900

135

1,035

1,481

18

Total

1,620

1,620

900

135

1,035

1,481

61,380

61,380

34,100

8,790

42,890

61,380

Demand stratum

WH
Home

Person groups or structural


property
Calculation step

PTV AG

Destination

Origin

Like home

Jobs

Zone

Zone Type

QP

1,860

1,860

2,000

1,253

3,410

3,410

7,000

4,384

1,860

1,860

2,000

1,253

1,240

1,240

1,700

1,065

147

Chapter 3: Demand model

744

744

2,500

1,566

558

558

1,600

1,002

124

124

2,000

1,253

1240

1,240

1,000

626

1,922

1,922

2,500

1,566

10

1,240

1,240

1,500

939

11

691

691

900

564

12

634

634

900

564

13

576

576

900

564

14

403

403

450

282

15

346

346

450

282

16

518

518

900

564

17

461

461

450

282

18

461

461

450

282

18,288

18,288

29,200

18,288

Total

Demand stratum

OH

Person groups or
structural property
Calculation step

148

Home

Destinati
on

Origin

Inhab.

Like
home

3.1

3.2

QP Inh.

QP Jobs
tert

QP Total

Jobs in tertiary sector and inhabitants

Zone

Zone Type

6,300

6,300

3,500

550

4,050

5,796

9,450

9,450

5,250

2,250

7,500

10,733

6,300

6,300

3,500

650

4,150

5,939

4,500

4,500

2,500

500

3,000

4,293

2,700

2,700

1,500

800

2,300

3,292

1,800

1,800

1,000

500

1,500

2,147

450

450

250

600

850

1,216

4,500

4,500

2,500

300

2,800

4,007

6,300

6,300

3,500

700

4,200

6,011

10

4,500

4,500

2,500

500

3,000

4,293

11

2,835

2,835

1,575

270

1,845

2,640

12

2,430

2,430

1,350

270

1,620

2,318

13

2,025

2,025

1,125

270

1,395

1,996

14

1,215

1,215

675

45

720

1,030

PTV AG

Chapter 3.2: Demand modeling procedures

15

1,215

1,215

675

45

720

1,030

16

1,620

1,620

900

270

1,170

1,674

17

1,620

1,620

900

135

1,035

1,481

18

1,620

1,620

900

135

1,035

1,481

61,380

61,380

34,100

8,790

42,890

61,380

Total

Demand stratum

OO
Home

Origin

Person groups or structural


property

Jobs in tertiary sector and inhabitants

Calculation step

2.1

2.2

2.3

Zone

Zone Type

QP Inh.

QP Jobs
tert

QP Total

4,200

3,500

550

4,050

3,864

6,300

5,250

2,250

7,500

7,156

4,200

3,500

650

4,150

3,959

3,000

2,500

500

3,000

2,862

1,800

1,500

800

2,300

2,194

1,200

1,000

500

1,500

1,431

300

250

600

850

811

3,000

2,500

300

2,800

2,671

4,200

3,500

700

4,200

4,007

10

3,000

2,500

500

3,000

2,862

11

1,890

1,575

270

1,845

1,760

12

1,620

1,350

270

1,620

1,546

13

1,350

1,125

270

1,395

1,331

14

810

675

45

720

687

15

810

675

45

720

687

16

1,080

900

270

1,170

1,116

17

1,080

900

135

1,035

987

18

Total

1,080

900

135

1,035

987

40,920

34,100

8,790

42,890

40,920

Demand stratum

OO
Destination

Person groups or structural


property
Calculation step

PTV AG

Jobs in tertiary sector and inhabitants


3.1

3.2

3.3

149

Chapter 3: Demand model

Zone

Zone Type

ZP Inh.

ZP Jobs tert

ZP Total

3,500

550

4,050

3,864

5,250

2,250

7,500

7,156

3,500

650

4,150

3,959

2,500

500

3,000

2,862

1,500

800

2,300

2,194

1,000

500

1,500

1,431

250

600

850

811

2,500

300

2,800

2,671

3,500

700

4,200

4,007

10

2,500

500

3,000

2,862

11

1,575

270

1,845

1,760

12

1,350

270

1,620

1,546

13

1,125

270

1,395

1,331

14

675

45

720

687

15

675

45

720

687

16

900

270

1,170

1,116

17

900

135

1,035

987

18

Total

900

135

1,035

987

34,100

8,790

42,890

40,920

Since all demand strata feature hard constraints, balancing can be performed immediately
after trip generation. First of all the total origin and destination traffic of each zone and of the
demand strata HW, HO, WH, OW is calculated and the resulting differences are compensated
in the OO demand stratum.
Note: Note that neither total origin and nor total destination traffic of this demand stratum
change.
Total HW+HO+WH+OH

150

Differences

Zone

16,800

14,422

2,378

26,600

31,373

4,773

16,800

14,709

2,091

11,800

10,993

807

7,080

10,121

3,041

4,860

6,558

1,698

1,180

5,263

4,083

11,800

9,429

2,371

PTV AG

Chapter 3.2: Demand modeling procedures

16,940

15,559

1,381

10

11,800

10,710

1,090

11

7,236

6,555

681

12

6,296

5,911

385

13

5,355

5,267

88

14

3,344

2,698

646

15

3,213

2,698

515

16

4,415

4,623

208

17

4,284

3,599

685

18

4,284

3,599

685

Total

164,086

164,086

13,804

13,804

OO before balancing
Zone

OO after balancing
Z

3,864

3,864

2,561

4,938

7,156

7,156

9,515

4,742

3,959

3,959

2,624

4,715

2,862

2,862

1,897

2,704

2,194

2,194

4,495

1,454

1,431

1,431

2,646

948

811

811

4,621

537

2,671

2,671

1,770

4,141

4,007

4,007

2,655

4,036

10

2,862

2,862

1,897

2,987

11

1,760

1,760

1,166

1,848

12

1,546

1,546

1,024

1,409

13

1,331

1,331

882

970

14

687

687

455

1,101

15

687

687

455

971

16

1116

1116

948

740

17

987

987

654

1,339

18

987

987

654

1,339

Total

40,920

40,920

4,0920

40,920

The results of operation EVA trip generation are stored in zone attributes.

PTV AG

Attribute

Subattribute

Meaning and range of values

HomeTrips

Demand stratum

Home trips for demand stratum


Range: floating point number

151

Chapter 3: Demand model

Attribute

Subattribute

Meaning and range of values

ProductionsTarget

Demand stratum

Productions for demand stratum, before taking account of


constraints
Range: floating point number

AttractionsTarget

Demand stratum

Same for attractions


Range: floating point number

Productions

Demand stratum

Productions for demand stratum after taking account of


constraints and balancing
Note
This attribute is only available after EVA trip generation if all
demand strata feature hard constraints, otherwise after
EVA trip distribution / mode choice only.
Range: floating point number

Attractions

Demand stratum

Same for attractions


Range: floating point number

3.2.2.3

EVA trip distribution and mode choice

In gravity models, trip distribution or destination choice is made according to the bilinear
approach (for example Kirchhoff 1970), using various evaluation or utility functions Wij.
Tij = Wij fq i fz j

Wij fqi fz j

( i = 1,..., m; j = 1,..., n)

Tij = Qi

j =1
j =1
m
m
Wij fqi fz j = Tij = Z j
i= 1
i =1
Hereby Tij is the number of trips from i to j, Wij is the cost function for the trip from i to j, Qi is
the production of zone i and Zj is the attraction of zone j. The factors fqi, fzj are calculated so
that productions and attractions are kept as marginal sums.
The EVA model generalizes this approach of a simultaneous trip distribution and mode choice
to a trilinear model.
Tijk = Wijk fqi fz j fa k

Wijk

fqi fz j fa k =

( i = 1,..., m; j = 1,..., n; k = 1,..., p)

Tijk = Qi

j =1 k = 1
j =1 k =1
m p
m p
Wijk fqi fz j fa k = Tijk = Z j
i= 1 k = 1
i =1 k =1
m n
m n
Wijk fqi fz j fa k = Tijk = VK k
i= 1 j = 1
i =1 j =1

152

PTV AG

Chapter 3.2: Demand modeling procedures

Here, index k is the mode (means of transport) and Wijk assesses the costs for the trip from i to
j by modes k. For each demand stratum c there is a separate equation system to be solved
independently. For more clarity index c has been dropped for all variables in the problem
formulations above.
For the trilinear case, besides origin and destination traffic, the total number VKk of trips with
mode k is required. There are two possibilities.

If EVA trip distribution and mode choice for the analysis case is performed, which means
without having run a pre-calculation for the same study area, specify the modal split as
input data.
If, however, a forecast case is calculated, the modal split of the analysis case can be reused. You thus assume that the modal split may change on single relations, but modal split
of the whole model (including all relations), however, remains unchanged.

The problem formulation is applicable in case of hard constraints. For weak, elastic or open
constraints equations will be replaced by inequations in the side conditions or a side condition
will be dropped completely. This will be dealt with when describing the problem solutions.
The models can be justified by the probability theory using Bayes axiom or the information
gain minimization. Both ways lead to the same result.
Minimizing the gain of information has the target that the deviations from a priori assessments
of trip relations which would lead to the actually desired trips road users have to experience are
as minor as possible, but which have become necessary due to the constraints of the system.
The demand matrix T can be interpreted as the solution to the convex optimization task

pijk
Minimum
I = pijk ld
wijk

ijk
Tijk
;
V

Wijk
Wrsl
rsl
taking account of the constraints. The solution is the trilinear equation system previously
determined.

with pijk =

wijk =

The parameter I represents the information gained through the replacement of distribution wijk
(solely determined by the weighting matrix) by distribution pijk (additionally derived from
marginal totals).

Weighting probabilities (impedance functions)


In general, the total trips costs include various factors (e.g. journey time, egress/access time,
monetary costs, number of passenger transfers etc.). In the EVA model, these are called
assessment types. In the EVA model the different assessments of each assessment type are
transformed separately by a utility function and then multiplied.
If caijk is the assessment of type a of a trip from i to j by mode k, then the following applies:

W ijk = M ijk C ijk P ijk


whereby

PTV AG

153

Chapter 3: Demand model

P ijk = [ f a' ( c a'ijk ) f a'' ( c a''ijk ) ] f a''' ( c a'''ijk )

aA

f a ( c aijk )

Here Mijk stands for the availability of mode k on OD pairs (i,j) and Cijk stands for the capacity
utilization of mode k on (i,j). a, a and a are the predefined assessment types: journey time,
competing walk time and external weighting matrix. A is the number of user-defined
assessment types.

Mijk and Cijk are defined independently from the demand stratum as follows:
OD type

Definition of Mijk and Cijk

Type 1

Mijk = mk(i) for all j, i.e. value of zone attribute mk set for source zone i
Cijk = ck(j) for all i, i.e. value of zone attribute ck set for destination zone j

Type 2

Mijk = mk(j) for all i, i.e. value of zone attribute mk set for destination zone j
Cijk = ck(i) for all j, i.e. value of zone attribute ck set for source zone i

Type 3

without accounting for home zone


Mijk = 1 for all i,j,k
Cijk = ck(i) ck(j)
including accounting for home zone

n mk ( n ) hn P nik P jnk

M ijk = --------------------------------------------------------------- hn
n

Cijk = ck(i) ck(j)

represents the product matrix from the


whereby hn stands for the home trips of zone n, P
top, but the predefined assessment type External weighting matrix is not included in the
product:

P ijk = [ f a' ( c a'ijk ) f a'' ( c a''ijk ) ]

aA

f a ( c aijk )

For demand strata of the origin-destination type 3 (which are calculated accounting for the
home zone), the assessment type External weighting matrix is used to produce a specific
weighting between zones and modes. This weighting has an immediate impact on the total
product, since it is not part of the scaling using home zones, as in the formula for Mijk. In all
other cases, this assessment type has the same effect as a user-defined one.
You can use different function types as fa evaluation functions. All distribution functions of the
gravity model (cf. chap. 5.1.4.17) can be taken, but additionally the EVA1, EVA2, Schiller and
Box-Tukey functions (see "Gravity model calculation" on page 174), too.
EVA1

EVA2

154

a
f (x ) = ( 1 + x ) ( x ) whereby ( x ) = 1 + exp( b cx )
b

x
f (x ) = 1 +
c

PTV AG

Chapter 3.2: Demand modeling procedures

Schiller

f (x ) =

1
x
1+
b

Logit

f (x ) = e (c x )

Kirchhoff

f (x ) = x c

Box-Cox

xb 1
c

f ( x ) = e

Box-Tukey

( x + 1 )b 1 / b ,
) whereby
(
c

x
=

f (x ) = e

Combined

f (x ) = a x b e (c x )

TModel

f (x ) =

None

ln( x + 1 ),

b >0
b =0

1
b
x + c xa

f(x) = x

In practice particularly the functions EVA1 and EVA2 have proved to be suitable. The EVA1
functions are monotonously falling with f(w) 1 for w 0. In illustration 53 some of them have
been illustrated. Their parameters can be interpreted geometrically.

Parameter marking the horizontal asymptote of function (w), thus influencing the degree of
approximation of the function f(w) to the w asymptote.

Parameter influencing the degree of approximation to the horizontal F(w)=1 in the proximity
of low assessment

c
b/c

Parameter influencing the slope of the function f(w)


Position of the inflection point WP=F/G of function (w) where the function (w) features the
greatest rise or the highest "impedance sensitivity"

The related elasticity functions are determined by

f ( w )=

1
G exp( F G w )
Ew

+ ln( 1 + w )
.
1 + exp( F G w )
1 + exp( F G w ) 1 + w

f ( w + h ) f ( w ) h df ( w )
w
=

is defined as the
f (w)
w
dw
f (w)
limit of the quotient of the relative variation of the function f and the relative variation of the
impedance w.

The elasticity function f ( w )= limh 0

It is obvious that the elasticity functions first take values near zero for low impedances, then for
a limited range in which the impedance sensitivity is at its highest take various values, but all
far from zero and for high impedances approximate the limit of -E.

PTV AG

155

Chapter 3: Demand model

Thus, this curve very much differs from the constant or linear elasticity functions of simple
power and exponential functions. Therefore, this type of function allows the adaptation to
various basic weighting situations (person groups, trip purposes, means of transport etc.). In
the range of low assessment or utility the weighting probability should be almost one, drop
further in the clearly noticeable range of assessment and utility which is relevant for the
respective type of traffic or purpose before asymptotically approximating zero. For example,
the assessment in the proximity of or in smaller towns plays a minor or no role at all for the road
users when choosing the destination or the means of transport (here mainly the random model
with WP = 1 is applicable).

f1(E=2; F=5; G=0,24)


f3(E=0,6; F=6; G=0,06)

f2(E=4; F=6; G=0,08)


f4(E=20; F=12;G=0,08)

1,1
1
0,9
0,8
0,7
f(w) 0,6
0,5
0,4
0,3
0,2
0,1
0
0 10 20 30 40 50 60 70 80 90 100 110120

0 10 20 30 40 50 60 70 80 90 100110 120
0
-5
-10
eps(w) -15
-20
-25
-30
Illustration 53: EVA1 function in dependence of impedance w

The EVA2 function has the following parameters.


a, b ...

156

Exponents whose product determines the asymptotic behavior for high impedance values.
For b > 1 the curve is similar to that of the EVA function (1).

PTV AG

Chapter 3.2: Demand modeling procedures

c ...

Scale parameter for impedance values.

f ( c ) = 1 / 2 applies.

The illustration 54 shows the influence of a and b on the progression of the function. The two
other parameters are both kept constant.
EVA2 Function (a variable)
1,0
0,9

Utility f(x)

0,8
0,7

a=0

0,6

a=1
a=2

0,5

a=3

0,4
0,3
0,2
0,1
100

95

90

85

80

75

70

65

60

55

50

45

40

35

30

25

20

15

10

0,0
Assessment x

EVA2 Function (b variable)


1,0
0,9
0,8

Utility f(x)

0,7
b=1

0,6

b=3

0,5

b=5

0,4

b=7

0,3
0,2
0,1

Assessment x

100

95

90

85

80

75

70

65

60

55

50

45

40

35

30

25

20

15

10

0,0

Illustration 54: EVA2 function in dependence of the parameters a and b

The Schiller function is a special case of the EVA2 function, however, with one parameter less.
As the first applications in practice have shown, the function can also be adapted sufficiently
well enough to observed data. Due to the lower number of parameters the calibration effort is
by far lower than for EVA2.

PTV AG

157

Chapter 3: Demand model

Problem solution 1: The trilinear FURNESS method


The mostly investigated method for solving bilinear problems in technical literature is named
after K. P. Furness (Furness 1962, 1965). However, in fact, Bregman had already applied this
method in the thirties (Bregman 1967a, 1967b). It can be generalized and transferred directly
to the trilinear case.
After you have specified start values for the trilinear FURNESS method

fqi (1) = fz j (1) = fak (1) = 1

(i = 1,..., m; j = 1,..., n; k = 1,..., K )

during iteration step p (p=1,2,), the system calculates approximations for fqi, fzj and fak as
follows.

fqi ( p + 1) =
n

Qi
K

Wijk fz j ( p ) fak ( p ) (i = 1,,m)


j =1 k =1
Zj

fz j ( p + 1) =

m K

Wijk fqi ( p + 1) fak ( p )

(j = 1,,n)

i =1k =1

VK k

fak ( p + 1) =

m n

Wijk fqi ( p + 1) fz j ( p + 1)

(k = 1,,K).

i =1 j =1

For convergence of the method (towards the solution of the trilinear problem), the condition for
unique solvability of the optimization problem is necessary and sufficient, i.e. existence of a
matrix Tijk that matches the constraints and for which Tijk = 0 is true for all pairs (i,j) with Wij =
0. This condition is fulfilled when Wij > 0 is true for all (i,j), since then the matrix with elements

Qi Z j fak
(the matrix that corresponds to the random model) can be chosen as a
V
feasible solution. For this special case A. W. Evans provided a convergence proof that also
allows for a (however rough) estimation of the convergence rate (Evans 1970). The practical
experience has shown that the method quickly converges in most application cases.
Tijk =

Problem solution 2: The trilinear Multi method


Another possibility to solve the problem is to set separate fixed point equations for the vectors
fqi, fzj and fak and use them to derive rules for determining successive approximations for these
vectors (Schnabel 1997). The Multi-Procedure can also be extended to the three dimensional
case (see "Projection" on page 188). Approximations for the solution of the trilinear problem
then can be determined according to the following iteration rule.

Tijk (1) = Wijk

158

(i = 1,...,m;

j = 1,...,n; k = 1,..., K )

PTV AG

Chapter 3.2: Demand modeling procedures

q ( p ) z j ( p ) ak ( p )
V
Tijk ( p + 1) = Tijk ( p ) i

qqi ( p ) zz j ( p ) aak ( p ) m n K

Trst ( p )
r =1 s =1t =1

(p = 1, 2,)
with

Qi
qi ( p ) =
n K
Tist ( p )
s =1t =1
n K

Tist ( p ) [zs ( p ) + at ( p )]

qqi ( p ) = s =1t =1
n K
2 Tist ( p )
s =1t =1

z j ( p) =

Zj
m K
Trjt ( p )
r =1t =1

m K

Trjt ( p ) [qr ( p ) + at ( p )]

zz j ( p ) = r =1t =1

m K

Trjt ( p )

r =1t =1

VK k
ak ( p ) =
m n
Trsk ( p )
r =1 s =1
m n

Trsk ( p ) [qr ( p ) + zs ( p )]

aak ( p ) = r =1 s =1

m n

Trsk ( p )

r =1 s =1

Strictly speaking the method presented solves the problem with hard constraints only. If some
constraints are weak or elastic, there will be an optimization problem with inequations as side
conditions instead of equations. At the example of weak constraints it is illustrated how the
problem and correspondingly its solution alters (according to Schiller 2004). It is assumed that
a demand stratum shows weak constraints on the destination side, which means attraction
calculated by trip generation constitutes an upper limit. Thus, the trilinear problem changes into

Tijk = Wijk fqi fz j fak

PTV AG

159

Chapter 3: Demand model

under the constraints

Tijk

= Qi

j k

Tijk
i k

Tijk

Z max
j
= VK k

i j
The procedure for multi-problem solving is mostly identical with the constraint equation
method, except that zj(p) and zzj(p) are calculated differently.

Z max
1
j

z j ( p ) = min
;
; fz j (0 ) = 1
fz
p
1
Z
p
(
)
(
)

ijk ( p ) (qi ( p ) + ak ( p ))

1
zz j ( p ) = min
; i k

fz
p
1
2
Z
p
(
)
(
)
j
j

If some demand strata do not feature hard constraints, not only has the method to be adapted
but also balancing has to be made up.
Note: Differences in marginal sums can only be balanced after trip generation if all demand
strata feature hard constraints.
In that case first of all the trilinear problem is solved for all demand strata except for the
balancing one. This results in the total productions and attractions of the zones covering these
demand strata and all modes. According to the formula for calculating productions and
attractions (see "EVA trip generation" on page 135), the productions and attractions of the
balancing demand stratum are modified. Finally Visum runs trip distribution and mode choice
for this last demand stratum, too.
The proceeding assumes that differences have to be balanced within the framework of the total
volume. This is only true if all modes are exchangeable, which means if they can be used
alternatively in a closed trip chain. If at least one mode cannot be exchanged, a second phase
begins after the total balancing in which calculations are performed for each non-exchangeable
mode separately and for all exchangeable modes jointly. Hereby, the productions and
attractions of the respective modes are calculated over the non-balancing demand strata,
their differences are compensated by an adaptation of the demand of the balancing demand
stratum, and based on that modified demand Trip distribution and Mode choice are calculated
for the last time. For non-exchangeable modes this last step corresponds to a simple mode
choice.
The implementation of the EVA model for trip distribution and mode choice has been
established in two separate operations. EVA Weighting uses skim matrices to calculate the
weighting matrices Wijk (one weighting matrix each per demand stratum). During EVA trip
distribution and Mode choice, the equation systems for determining the demand matrices are
set up according to the constraints of the demand strata and solved by applying one of the
above-described methods. The result of the operation is one demand matrix per demand

160

PTV AG

Chapter 3.2: Demand modeling procedures

stratum and mode. You can also display the balance factors for productions and attractions fqi
and fzj, that result from the equation system. The balance factor for mode choice fak is
calculated for analysis, but not for forecast scenarios.
The EVA weighting procedure can be applied to all active OD pairs or only to those OD pairs
whose origin or destination zone are active. This allows you to perform an analysis based on
filtering by several OD pairs with different parameters. This option is not available for combined
distribution and mode choice, as for successful balancing, all traffic types need to be
accounted for in one step.

3.2.3

Activity chain based model (tour-based model)


The tour-based model is a disaggregated, behavior-oriented demand model which allows the
planner to include all kinds of data relating to socio-demography and traffic policy issues. The
tour-based model calculates three logical work units.
1. Trip generation (calculating the home trip)
2. Trip distribution (determining the trip destination)
3. Mode choice
These three logical units are not processed separately in succession by the tour-based model,
but are interlocked. Especially steps 2 and 3, Trip distribution and Mode choice are carried out
simultaneous in a single procedure. In all three work units two important concepts have been
implemented for the tour-based model: Calculation on the basis of groups with homogeneous
behavior and activity chains.

3.2.3.1

Tour-based data model

The tour-based model is based on the assumption that external activities cause mobility. In the
following examples previously defined activities are already being used (see "Activities, activity
pairs, activity chains" on page 122).
An activity chain describes a sequence of typical activities during a person's day. An example
would be: Home Work Shopping Home (HWOH). Such a sequence of activity pairs
implies trips, in this example here three different trips: HW, WO, OH. The average mobility
program of persons is described by activity chains for the tour-based model.
You can find the demand object activity chain attributes in the general description of the
demand objects (see "Activities, activity pairs, activity chains" on page 122).
Some changes in the demand objects, which are especially necessary for the tour-based
model, are described below.
Note: In a Visum-tour-based demand model, a demand stratum is specified by exactly one
person group (e.g. E+c) and one activity chain (e.g. HWOH). In the other demand models,
several person groups can be assigned to one demand stratum.

Changes to activities in the tour-based model


Each activity from the activity chain, apart from the home activity, has to be assigned to exactly
one structural property, whose value flows in as target potential into the trip distribution.
The following table shows examples for activities and respective structural properties.

PTV AG

161

Chapter 3: Demand model

Activity

Structural property

Structural property value = target potential


Number of jobs

Work ('W')

Jobs

Shopping ('O')

Shopping possibilities Retail sales floor

Recreation ('R')

Recreational facilities

Number of mentions of the zone as recreation destination


in a household survey

School ('S')

School places

Number of school places (up to 18 years)

University ('U')

University places

Number of university places

You can specify whether a possible destination-binding can be considered for trip distribution,
per activity. If desired, a constraint for the destination side (for example hard, weak, elastic,
open) can be defined analog to the EVA demand model using two real-valued factors
ConstraintMinFactorDest and ConstraintMaxFactorDest. Depending on the constraint on
origin and destination side, the doubly-constrained trip distribution is calculated for each
activity transfer.
This results in the following new attributes:
Type of demand Attribute and range of values
object

Meaning

Activity

StructuralPropertiesCodes
Range: set of structural properties

Reference to the activity relevant structural


properties

Activity

ConstraintDest
Range: bool {0, 1}

Destination-sided coupling during trip distribution


(yes / no). Home activity always =1.

Activity

ConstraintMinFactorDest /
ConstraintMaxFactorDest
Range: floating point number 0

Factor for the lower or upper limit of the


constraint on destination side, if ConstraintDest =
1.
For home activity, both factors are always = 1.0.

Changes to activity pairs in the tour-based model


The tour-based model offers a hourly calculation of the demand. This calculation requires as
input, proportional time series which are defined separately per activity pair and person group.
This results in the following new attribute:

162

Type of demand
object

Attribute and range of values

Subattribute

Meaning

Activity pairs

TimeSeriesNo
Range: set of standard time
series (see "Time series" on
page 121)

Person group

Reference to a standard
time series, which has to be
proportional

PTV AG

Chapter 3.2: Demand modeling procedures

3.2.3.2

Tour-based model trip generation

Trip generation uses a list of group-specific activity chains, which for example, can be
determined from the sample of the KONTIV 89 (EMNID 1991) by applying a PTV company
optimization procedure for activity chains. For each activity chain probabilities of your daily
practice have to be specified for each person group. The following table (to calculate the
probabilities, these values must be divided by 100) contains examples of activity chain
percentages for each person group.
E+c

E-c

NE+c

NE-c

Appren

Stud

SPup

PPup

Child

HWH

74.25

62.60

8.18

2.82

33.48

11.08

1.92

0.30

0.00

HSH

0.00

0.00

0.00

0.00

47.57

0.00

0.00

0.00

0.00

HPH

17.42

25.94

60.60

62.93

12.37

23.91

12.99

9.08

0.00

HRH

27.03

25.32

52.50

39.74

38.08

37.33

40.12

38.67

0.00

HPH

0.00

0.00

0.00

0.00

0.00

0.00

0.00

74.99

0.00

HSH

0.00

0.00

0.00

0.00

0.00

45.19

0.00

0.00

0.00

HOH

0.90

1.82

0.96

0.47

0.00

0.00

80.48

0.00

0.00

HWWH

3.12

0.85

0.13

0.06

0.52

0.16

0.11

0.00

0.00

HWOH

4.67

7.05

0.96

0.33

1.79

0.80

0.37

0.00

0.00

HWRH

1.64

1.46

0.18

0.02

0.86

1.56

0.09

0.00

0.00

HWOH

0.08

0.04

0.00

0.00

0.00

0.00

0.00

0.00

0.00

HSWH

0.00

0.00

0.00

0.00

0.16

0.00

0.00

0.00

0.00

HSSH

0.00

0.00

0.00

0.00

0.11

0.00

0.00

0.00

0.00

HSPH

0.00

0.00

0.00

0.00

0.97

0.00

0.00

0.00

0.00

HSRPH

0.00

0.00

0.00

0.00

0.00

0.23

0.00

0.00

0.00

HSRRH

0.00

0.00

0.00

0.00

0.00

0.55

0.00

0.00

0.00

HSRSH

0.00

0.00

0.00

0.00

0.00

0.76

0.00

0.00

0.00

HSSOH

0.00

0.00

0.00

0.00

0.00

0.17

0.00

0.00

0.00

HSSSH

0.00

0.00

0.00

0.00

0.00

0.12

0.00

0.00

0.00

HOWWH

0.01

0.00

0.00

0.00

0.00

0.00

0.00

0.00

0.00

HOWPH

0.01

0.04

0.00

0.00

0.00

0.00

0.00

0.00

0.00

HOWRH

0.01

0.00

0.00

0.00

0.00

0.00

0.03

0.00

0.00

HOWOH

0.00

0.00

0.00

0.00

0.00

0.00

0.12

0.00

0.00

HOPPH

0.00

0.00

0.00

0.00

0.00

0.00

0.25

0.00

0.00

HOPRH

0.00

0.00

0.00

0.03

0.00

0.00

0.14

0.00

0.00

HOPOH

0.00

0.00

0.00

0.00

0.00

0.00

0.04

0.00

0.00

HPRRH

0.00

0.00

0.00

0.01

0.00

0.00

0.17

0.00

0.00

HOROH

0.00

0.00

0.00

0.00

0.00

0.00

0.11

0.00

0.00

HOOOH

0.00

0.00

0.00

0.00

0.00

0.00

0.03

0.00

0.00

Table 44: List of the activity chains: mobility rates per person group in %

PTV AG

163

Chapter 3: Demand model

The sum of the probabilities of a person group is often greater than 1.0 (or 100 %), because a
person can complete more than one activity chains one after the other in a day (for example,
person group E+c first HWH, then HRH).
The list displayed above, describes an average mobility for persons depending on the group
they belong to. In the tour-based model, trip generation (i.e. determining the absolute number
of activity chains and thus the trips starting from any of the individual zones) is calculated by
multiplying the inhabitants of each person group with the probabilities of all activity chains. Trip
generation can be limited to the active zones.
Thus, in the tour-based model, trip generation (the number of trips created with each activity in
the activity chain) is determined together with the number of inhabitants and distribution of
person groups. The result is saved in the zone attribute Home trips for each demand strata.

Example of trip generation with the tour-based model


2,000 employees with a car (E+c) live in zone 1. After the activity chain distribution above, run
the activity chain HWOH per day with 4.67 % probability. This is why there are 2,000 4.67 %
= 93.4 chains of the type HWOH. Consequently, home trips for the demand stratum E+c x
HWOH add up to 93.4.
The 2,000 persons in this activity chain produce a total of 3 93.4 = 280.2 trips, namely 93.4
HW trips and just as many for WO and OH.

3.2.3.3

Tour-based model: trip distribution / mode choice combined

Using tour-based calculation, you can save output matrices with different aggregation levels.
The demand matrices are calculated from possible combinations of person group, mode,
production and attraction activity, and time interval.

Trip distribution: route links through destination choice according to activities


Depending on the destination activity of a trip, the tour-based model assigns it to a destination
zone. This destination zone is chosen depending on several factors.

The utility matrix, which shows the separation from the origin zone (spatially and trafficwise)
The utility is inversely proportional to impedance values, such as run times or distances, so
that the greater the run time or distance to a destination zone, the less its utility.
The utility matrix may also include the log sum of mode-specific use. In this way, specific
skims (e.g. PrT journey time or PuT number of transfers) are included in the total utility with
their share in the respective mode.

The target potential of the zones competing as destinations


The impact of utility defined via the utility function parameters for each group and each
destination activity
These parameters can be estimated beforehand (see "Estimate gravitation parameters
(KALIBRI)" on page 173)

This is how a multitude of trip chains is created through each activity chain. The result of trip
distribution is not only a total traffic matrix, but also a set of all route chains.

164

PTV AG

Chapter 3.2: Demand modeling procedures

With the destination choice model, the tour-based model needs a target potential Zj for each
activity. The target potential specifies the quantitative attractiveness of a zone. This target
potential for each zone j, corresponds to the value of the structural property (see "Tour-based
data model" on page 161) that belongs to the activity.
The utility function f(uij) is pivotal in the destination choice model. It specifies the probability Pij
with which one of the zones j is selected as destination zone (from all destination alternatives)
of origin zone i.

F ij = Q i P ij
Z j f ( u ij )
P ij = -----------------------------------------B

k = 1 Z k f uik

whereby

Fij

Number of trips from zone i to zone j

Qi

Productions in zone i

Pij

Choice probability of destination j for origin zone i

Zj

Target potential in zone j

Index of zones (with k = the smallest zone number and B = the number of zones)

whereby uij describes the utility relation ij and the utility function f(uj)) (e.g. of the type Logit) can
consequently be defined as f ( u ij ) = e

cu ij

. All other evaluation functions of the EVA demand

model can also be used as utility functions in the tour-based model (see "EVA trip distribution
and mode choice" on page 152).
In this case, the choice of parameter c for every activity is pivotal for destination choice. c
stands for the influence of utility on the destinations of the respective activity. If c = 0, then the
utility uij has no influence on the choice of destination. The larger c is, the larger is the impact
of utility uij on the choice of the destination (see "Gravity model calculation" on page 174).
You define function parameters for each person group.
To give you a better idea of what the three main model elements of destination choice, namely
destination potential, utility function and utility matrix, stand for, we will continue with the
example we used for trip generation (see "Example of trip generation with the tour-based
model" on page 164).

Example of trip generation


A Logit utility function ( f ( u ij ) = e

cu ij

with parameter c = 0.4) is used to represent the

changeovers from and to the individual activities.


The 93.4 trips of the activity pattern HW have to lead from the origin (zone 1) to the potential
destination zones, containing jobs. The tour-based model distributes these 93.4 trips to the
destination zones, according to the previously described destination choice model.

PTV AG

165

Chapter 3: Demand model

To make it easier, let us assume that zone 2 is the only zone with jobs, which therefore has a
positive destination potential for the activity work. Expressed in numbers this would be
approximately Z1 = 0, Z2 = 100, Z3 = 0. The tour-based trip distribution formulas produce the
following results P11 = 0, P12 = 1 and P13 = 0, and therefore F11 = 0, F12 = 93.4 and F13 = 0.
Zone 2 is therefore the destination of all trips of zone 1.
Note: The definition of the utility function in this case does not influence the calculation.
After the activity work, based on zone 2, the probability for the choice of shopping destinations
is calculated for the subsequent trips WO. It is assumed, that the destination potentials for the
activity "Shopping" are defined as follows: Z1 = 0, Z2 = 50, Z3 = 50. Based on travel times and
distances, the utility defined for changeover WO, with the relation 2-2, is twice as high as the
changeover with the relation 2-3, thus approximately u22 = 2 and u23 = 1. The tour-based trip
distribution formulas produce the following results P21 = 0, P22 0.6 and P23 0.4, and
therefore F21 = 0, F22 56.0 and F23 37.4. 40 % of the trips thus lead to zone 3 and 60 % to
zone 2 (i.e. trips within the cell).
Here, multiplication of the destination probability of the work and shopping destinations takes
place in the system.
For the last activity pair of the chain, namely PH, destination choice is no longer necessary,
because zone 1 as a residential district and origin of the first trip of the chain, is also the
destination of the last trip of the chain.
This results in the following transition matrices.

Zone

93.4

93.4

Total

93.4

93.4

93.4

166

Matrix F1 for the first activity transfer (Destination activity W)


1

Matrix F2 for the second activity transfer (Destination activity O)

Zone

93.4

93.4

Total

56.0

37.4

93.4

56.0

37.4

PTV AG

Chapter 3.2: Demand modeling procedures

Matrix F3 for the third activity transfer (Destination activity H)

Zone

93.4

93.4

Total

93.4

56.0

56.0

37.4

37.4

Summed up, the following total demand matrix applies FG.


Zone

280.2

280.2

Total

93.4

149.4

37.4

93.4

93.4

149.4

56.0

56.0

37.4

37.4

37.4

Summary of this destination choice example

HW: 100 % leave zone 1 with destination zone 2


WO: 60 % remain in zone 2 and 40 % leave zone 2 to zone 3
OH: 100 % return to zone 1.

The corresponding route chains are as follows:

1-2-2-1: 93.4 100 % 60 % 100 % = 56.0


1-2-3-1: 93.4 100 % 40 % 100 % = 37.4

The following route chains have been created:

56.0 route chains 1-2-2-1


37.4 route chains 1-2-3-1

Notes: The following behavioral aspects should be taken into consideration when you define
the utility parameters.
Traffic behavior analyses show, that persons with a car cover greater distances than
persons without a car. Accordingly, the absolute value of parameter c of the Logit function
for groups E+c and NE+c have to be smaller than for groups E-c or NE-c.
This also complies with the empirical perception, to give activity Work a c parameter with
a low absolute value, rather than for example activity Shopping.
The tour-based model allows specific utility matrices to be imported for each activity.
Combinations of distances and journey times can be used as a basic parameter in utility
matrices.

PTV AG

167

Chapter 3: Demand model

Note: The absolute value of a destination potential is first of all irrelevant, because it only
flows into the destination choice model comparatively to the sum of destination potentials of
all zones. Destination potential " jobs = 1,000" for a zone does not necessarily mean that the
tour-based model produces 1,000 trips for destination activity work. In fact, the destination
traffic depends on the product of destination potential and utility function value in relation to
the other zones.
If, however, the absolute value of the destination potential of an activity is very important, as for
example for the number of jobs, this can flow into the calculation via the Destination-sided
attraction option. If there are approx. 6,000 jobs in the study area, 1,000 jobs mean there is a
relative destination potential of 1,000/6,000 = 1/6 for the activity work. If a demand stratum has
a total of 3,000 home trips, the absolute zone destination potential standardized to the total of
home trips for this demand stratum is 3 1/6 = 500. This absolute value for the demand stratum
is used as a constraint in the doubly coupled gravity model (see "Gravity model calculation" on
page 174).
You can save your trip distribution results in an aggregated form to total demand matrices per
person group as well as per combination of time interval, mode, origin and destination activity.

Mode choice: discrete distribution model


The tour-based demand model has a behavior-oriented concept, which models the following
aspects of the decision-making of road users.

The socioeconomic position and the mode availability of the person making the decision
(by differentiating according to person groups)
Different attributes of all modes (through the utility model)
Freedom of choice restrictions within trip chains (by definition of exchangeable and nonexchangeable modes)

This decision problem is illustrated in a discrete distribution model, which specifies the
probability for mode choice in every available route link.
To do so, the subjective use has to be calculated in dependency of the mode skims (in-vehicle
time, access and egress times, fare, etc.). If required, you can define several utilities per
destination activity.
This model has the following functional form.

f ( u ijm )
P ijm = -----------------------------M

k = 1 f ( uijk )

whereby

168

i, j
m

Indices of the traffic zones

Pmij

Probability of selecting mode m for trip from i to j

umij

Utility when choosing mode m for trip from i to j

Index of modes (M = total number)

PTV AG

Chapter 3.2: Demand modeling procedures

f ( u ijm ) can e.g. be a Logit utility function and thus be defined as f ( u ijm ) = e cu ij . As an
alternative, all available types of evaluation functions can be used from the EVA demand
method as a utility function for the tour-based mode choice (see "EVA trip distribution and
mode choice" on page 152).
As a base parameter for the utility matrices any distance combinations and mode specific
skims can be used, such as travel times, access and egress times, and fares. You can also use
the LogSums of mode-specific use as an input parameter.
Last but not least, we would like to explain the importance of the route chain concept for mode
choice.
In Visum the modes are divided into the following groups:

exchangeable modes (generally walk, passenger and public transport)


non-exchangeable modes (car, bike)

The tour-based model calculates a discrete distribution model (for example Logit) when first
calculating the trip of each route link (for a person group) and chooses one from all modes. If
the first mode is a non-exchangeable mode, the entire trip chain is maintained independent of
the attributes of this mode of the successive trip. If an exchangeable mode was selected for the
first trip, mode choice is carried out for the remaining chain trips, however, only within the
exchangeable modes.

Example of mode choice


We will continue with the example from the trip distribution (see "Example of trip generation" on
page 165) and will determine the matrices for each activity transfer for the three modes Car
(C), PuT (X) and Walk (W). Only mode P cannot be exchanged. The set of exchangeable
m

modes X and W in short is also designated with A. A Logit utility function f ( u ijm ) = e cuij (with
parameter c = 0.4) is used again to represent the changeovers from and to the individual
activities. The utility matrices um for each mode m are provided by

Zone

PTV AG

uC

uX

Zone

169

Chapter 3: Demand model

uW

Zone

After analyzing the formula above, the following probability matrices apply.

PC

Zone

0.472

0.526

0.526

0.526

0.472

0.472

0.526

0.472

0.472

Zone

PX

0.316

0.237

0.237

0.237

0.316

0.316

0.237

0.316

0.316

Zone

PW

0.212

0.237

0.237

0.237

0.212

0.212

0.237

0.212

0.212

PA = PX + PW

Zone

0.528

0.474

0.474

0.474

0.528

0.528

0.474

0.528

0.528

Interesting are also the probabilities for modes X and W within the exchangeable modes.

PAX = PX / PA

Zone

170

0.598

0.5

0.5

0.5

0.598

0.598

PTV AG

Chapter 3.2: Demand modeling procedures

Zone

0.5

0.598

0.598

PAW = PW / PA

Zone
1

0.402

0.5

0.5

0.5

0.402

0.402

0.5

0.402

0.402

The matrix of the first non-exchangeable mode Car for all activity transfers is calculated. The
matrix for the first activity transfer is the product of PC with the total demand matrix F1 of the
first transfer.

Total demand matrix F1 for the first activity transfer (Destination activity W)

Zone

93.4

93.4

Total

93.4

93.4

93.4

Matrix FP1 for mode C and the first activity transfer (destination activity A)

Zone

49.12

49.12

Total

49.12

49.12

49.12

With the next activity changeover, these 49.12 trips will be distributed across zones 2 and 3
according to the distribution probabilities (P22 = 0.6 or P23 = 0.4).

Matrix FC2 for mode C and the second activity transfer (Destination activity O)

Zone

49.12

49.12

Total

29.47

19.65

49.12

10

29.47

19.65

Finally, the trips have to end back at the last activity transfer in their origin zone 1.

PTV AG

171

Chapter 3: Demand model

Matrix FC3 for mode C and the third activity transfer (Destination activity H)

Zone

49.12

49.12

Total

49.12

29.47

29.47

19.65

19.65

Summed up, the following Car total demand matrix applies: FCT
Zone

147.36

147.36

Total

49.12

88.59

19.65

49.12

49.12

88.59

29.47

29.47

19.65

19.65

19.65

To determine the total demand matrix for non-exchangeable modes, this Car matrix is
subtracted from the total demand matrix FT (from trip distribution).

FT

Zone

280.2

280.2

Total

93.4

149.4

37.4

93.4

93.4

149.4

56.0

56.0

37.4

37.4

37.4

The difference first results in the total demand matrix for all non-exchangeable modes.

FA

Zone

132.84

132.84

Total

44.28

70.81

17.75

44.28

44.28

70.81

26.53

26.53

17.75

17.75

17.75

For this matrix mode choice now takes place within the exchangeable modes PuT and Walk,
to obtain the total demand matrices for modes PuT and Walk. The matrix is multiplied with the
probabilities PAX and PAW.

172

PTV AG

Chapter 3.2: Demand modeling procedures

PuT total demand matrix FX

Zone

70.75

70.75

Total

22.14

38.00

10.61

22.14

22.14

39.74

13.27

15.86

10.61

8.87

8.87

Walk total demand matrix FW

Zone

62.09

62.09

Total

22.14

32.81

7.14

22.14

22.14

31.07

13.26

10.67

7.14

8.88

8.88

Make sure that the Car total demand matrix has identical row and column sums for each zone,
whereas this is not mandatory for the PuT and Walk matrices.
The mode choice results are saved in an aggregated form to demand matrices per person
group and mode. In addition, you can limit the usage of time interval and origin and destination
activity data for matrices with disaggregated data.

3.2.4

Estimate gravitation parameters (KALIBRI)


The Estimate gravitation parameters function (short KALIBRI) allows you to calibrate two
different utility functions (determine parameters a, b and c) for the gravity model used for trip
distribution.
1.

( )

f U ij = a U ij b e

c U ij

whereby

Uij

Value of the utility (for example distance or travel time) between zone i and zone j

a,b,c

Parameters to be estimated

2.

( )

f U ij = a e

cU ij

whereby

Uij

Value of the utility (for example distance or travel time) between zone i and zone j

a,c

Parameters to be estimated

The KALIBRI function adjusts these utility functions to a given trip length distribution.

PTV AG

173

Chapter 3: Demand model

Then the Trip distribution function calculates the traffic flow Fij (from zone i to zone j) with the
aid of the gravity model and known data, namely the source traffic Qi (of zone i), destination
traffic Zj (of zone j) and the parameters a, b, c (or a, c) specified here (see "Gravity model
calculation" on page 174).
The KALIBRI function provides two options that allow you to estimate the parameters for the
gravity model.

singly constrained production


doubly constrained (Multi procedure)

Parameters a, b, c or a, c respectively are determined in an iterative process. The utility function


is transformed during this process; with

( )

(2)

( )

(3)

ln f U ij = ln a + b ln U ij + c U ij
or

ln f U ij = ln a + c U ij

Within each KALIBRI iteration a temporary demand matrix is calculated (for example via Multi
procedure with option doubly-constrained gravity model). The resulting values of the utility
function are smoothed by linear regression until the maximum number of KALIBRI iterations is
reached or the values do not change anymore. The smoothed values then describe a function
of type (2) or type (3).

3.2.5

Gravity model calculation


The Gravity model is a mathematical model for trip distribution calculation (see "Trip
distribution" on page 129 and "Tour-based model: trip distribution / mode choice combined" on
page 164). It is based on the assumption that the trips made in a planning area are directly
proportional to the relevant origin and destination demand in all zones and the functional
values of the utility function between the zones (Ortzar 2001).
The gravity model calculates a complete matrix of traffic relations Fij, using the OD pairs of
marginal totals (origin and destination traffic of the individual zones). A consistent utility matrix
of the planning region is required.
The gravity model works with distribution parameters, therefore with values within the utility
function, which map the reaction of road users to distance or time relations. These parameters
are determined by comparing the demand per OD pair arising from the model, with the counted
demand per OD pair (calibration).
The capability of the models to predict future conditions (forecasting) depends on whether they
manage to predict the behavior of road users in relation to the network impedances, as well as
knowledge of the model input data applicable for the future (for example future travel demand).
General form of the distribution formula

F ij = k ij Q i Z j f ( U ij ) whereby
Logit

174

f ( U ij ) = e

cU ij

PTV AG

Chapter 3.2: Demand modeling procedures

Kirchhoff

f ( U ij ) = U ij

Box-Cox

f ( U ij ) = e
Combined

U ij 1
c -----------------b

f ( U ij ) = a U ij e

TModel

cU ij

1
f ( U ij ) = ---------------------------b
a
U ij + cU ij

The distribution formula is referred to an attraction or utility function, with the following
parameters.

Uij

Value for the utility between zones, for example distance or travel time from zone i to zone j

Qi

Origin zone i

Zj

Destination zone j

kij

Scaling factor (attractiveness factor) for OD pair zone i to zone j

Number of zones

Determining the scaling factor kij and formulating the utility function f(Uij) are essential for
various modifications and extensions.
The scaling factor kij must be chosen so that the boundary conditions of the distribution models
n

j = 1 Fij

= Qi

(4.1)

= Zj

(4.2)

and
n

i = 1 Fij

are (at least approximately) fulfilled.


Retaining only the first direction of distribution, we speak of production distribution. Retaining
only the second direction of distribution, we speak of attraction distribution. Retaining both
directions of distribution at the same time, we speak of doubly constrained. For coupling in

terms of production kij only depends on i, so we write k i .


For logical reasons, coupling for production requires that there are as many free parameters as
there are zones.
This leads to the formulation

F ij = k i Q i Z j f ( U ij )
with the following secondary conditions for zone i.
n

j = 1 Fij
PTV AG

= Qi

175

Chapter 3: Demand model

From the n secondary conditions, all ki can thus be determined by substitution in the
distribution function:
n

Qi =

j = 1

F ij =

j = 1

k i Q i Z j f ( U ij ) = k i Q i

j=1

Z j f ( U ij )

This results in

1
k i = ------------------------------------------ for Qi 0
n

j' = 1 Zj' f ( Uij' )

This produces a destination choice model of production distribution.

Q i Z j f ( U ij )
F ij = ------------------------------------------ for all i, j
n

j' = 1 Zj' f ( Uij' )

The destination choice model of attraction distribution is derived analogously.

Q i Z j f ( U ij )
1
F ij = ------------------------------------------- for all i, j with k j = ------------------------------------------n

i' = 1 Qi' f ( Ui'j )

i' = 1 Qi' f ( Ui'j )

The adjustment of the model to reality (calibration) by variation of the free parameters is very
important.
Since the input parameters Qi and Zj have been specified, the only free parameters that remain
besides the scaling factors ( k and k ) are the parameters of the utility function f(Uij .
i

Since for doubly constrained calculation both directions of the distribution, (4.1) and (4.2) must
be met at the same time, the following must also apply for the scaling factors k and k as well
i

as k i = kj for i = j. In practice, however, this can seldom be achieved, so a true doubly-

constrained calculation can only be achieved with much more complex iteration models.
As an iteration model the Matrix Editor uses the so-called Multi procedure according to Lohse
(Schnabel 1980) (see "The multi-procedure according to Lohse (Schnabel 1980)" on
page 189).
The general form of the utility function f(Uij) is
b

f ( U ij ) = a U ij e

cU ij

It is depicted for several b and c parameters in the following two figures.

176

PTV AG

Chapter 3.2: Demand modeling procedures

Attractiveness with a = 1 and b = 0


1
0,9

f(Uij)

0,8
0,7

c = -0,01

0,6

c = -0,1

0,5
0,4

c = -0,3
c = -0,5

0,3

c = -1

0,2
0,1
0

Uij
0

10

12

14

16

18

20

Utility between zone i and zone j

Attractiveness with a = 1 and c = -0,1


2
1,8
1,6
1,4
b = 0,1

f(Uij)

1,2

b = 0,3

b = 0,5

0,8

b = 0,7

0,6
0,4
0,2
0

Uij
0

10

15

20

25

30

35

40

Utility between zone i and zone j

Notes: Choose a suitable specification for the utility functions, which means suitable
parameters. Among other things, the specification depends on the trip purpose and the mode
used. A trip to work is for example, on average longer than a trip for shopping. This means
that the utility function for the trips to work, depending on the town's size, is only slightly
dependent on the use (distance or travel time) or not at all. Shopping trips on the other hand,
are much more dependent on the use.
The use of a trip distribution model can therefore call for a separation of the travel demand
based on the trip purpose. This depends essentially on the requirements in terms of accuracy
and the demands on the matrix to be calculated. Benchmark figures for the percentage split
based on the trip purpose can be obtained for example from the KONTIV 89 (EMNID 1991)
or local surveys.
The following four examples show gravity models that are differently constrained and with and
without balancing.

Example 1: Gravity model singly constrained in terms of production, with and


without balancing
The effect of the location factor on the calculation of the trip distribution according to the gravity
model depends on the type of coupling of the gravity model.

PTV AG

177

Chapter 3: Demand model

With the distribution method that includes coupling for EITHER attraction or production, the
source or destination traffic is adjusted to the marginal totals in the code file. The location factor
then only affects the "complementary" destination or origin demand. However, the following
applies
n

j = 1 Zj

i = 1 Q i k i

or

i = 1 Q i

j = 1 Zj kj

whereby ki or kj are attractiveness factors of the i or j zone.


With the distribution method that includes coupling for attraction AND production, the impact of
the attractiveness factor on the origin and destination traffic depends on the function command
in the code file. If for example $GQH is given as function command, the origin demand is
changed by the location factor that is listed in the same line as the factor within the code file.
However,
n

j = 1 Zj + i = 1 Qi ki

i = 1 Qi = j = 1 Z'j ----------------------------------------------------------2

with ki being the attractiveness factor of the i zone.

Input file Utility

Zone numbers
1
2.66

*
*

1.00
0.33
0.33
1.00

2
1.75
2.08
0.50
2.33
0.50
1.41
0.25
2.08
0.50

3
1.99

4
1.50

0.33

0.25

1.00

0.50

0.33

0.50

0.33

0.25

* 7.90

Input data for calculation without balancing

*Zone
1
2
3
4

Production
10.0000
20.0000
30.0000
40.0000

Attraction
50.0000
10.0000
20.0000
20.0000

Factor
0.50000000
1.00000000
1.00000000
1.00000000

External
0
0
0
1

The parameters are set as follows:

178

Combined utility function (exponential)


Parameter a = 1, b = 0.5 and c = -1
Singly-constrained for production without balancing

PTV AG

Chapter 3.2: Demand modeling procedures

Result matrix

Zone numbers
1
36.76

*
*

2
15.91
10.00
3.11
1.45
20.01
6.76
2.81
30.00
9.97
3.76
40.00
16.92
7.89

3
30.79

4
16.55

2.80

2.64

4.82

5.62

7.98

8.29

15.19

0.00

100.01

Input data for calculating balancing and scaling according to average value

*Zone
1
2
3
4

Production
10.0000
20.0000
30.0000
40.0000

Attraction
50.0000
10.0000
20.0000
20.0000

Factor
0.50000000
1.00000000
0.30000000
1.00000000

External
0
0
0
1

The parameters are set as follows:

Direction of the distribution according to the production distribution with boundary sum
balancing enforced by the multi procedure.
Combined utility function (exponential)
Parameter a = 1, b = 0.5 and c = -1
Scaling according to mean value of both sums
Max. number of iterations = 10, Quality factor = 3
Result matrix

Zone numbers
1
32.99

2
13.19
8.04
2.22
0.94
16.10
4.62
1.74
24.16
6.95
2.38
32.19
19.20
8.13

*
*

80.49

3
7.92

4
26.39

0.56

4.32

0.93

8.81

1.57

13.26

4.86

0.00

Example 2: Gravity model singly-constrained for production, with balancing

Input file Utility

Zone numbers

*
*

PTV AG

1
2
166.183 107.560
165.571
0.001
22.700
107.414
22.700
0.001
90.008
35.926
16.284
134.633
50.387
31.017
155.524
57.169
37.558

3
88.972

4
134.710

5
155.725

35.183

50.387

57.300

15.991

31.017

37.705

0.001

15.153

22.644

15.153

0.001

38.075

22.644

38.152

0.001

653.150

179

Chapter 3: Demand model

Input data

*Zone
1
2
3
4
5

Production
18990.0
4960.0
7110.0
16080.0
2300.0

Attraction
18990.0
4960.0
7110.0
16080.0
2300.0

Location factor and zone property external are not specified. Default values are used.
The parameters are set as follows:

Direction of the distribution according to the production distribution with boundary sum
balancing enforced by the multi procedure.
Combined utility function (exponential)
Parameter a = 1, b = 0.5 and c = -1
Scaling according to the production total
Max. number of iterations = 10, Quality factor = 3
Result matrix

Zone numbers

*
*
*
*
*
*
*

1
2
18990.000 4959.951
1
18990.000
18990.000
0.000
2
4959.999
0.000 4959.897
3
7110.000
0.000
0.054
4
16080.000
0.000
0.000
5
2300.000
0.000
0.000
49439.999

3
4
7109.758 16080.290

5
2300.000

0.000

0.000

0.000

0.102

0.000

0.000

7109.426

0.520

0.000

0.230 16079.770

0.000

0.000

0.000

2300.000

Example 3: Gravity model singly-constrained for attraction, without balancing

Input file impedances

* Zone numbers
1
2
1.00
0.50
0.33
0.50
0.33
0.25
1.00
0.50

3
0.33
1.00
0.33
0.33

4
0.25
0.50
0.50
0.25

Input data for marginal totals

*Zone
1
2
3
4

Production
10
20
30
40

Attraction
50
10
20
20

The parameters are set as follows:

Singly-constrained for attraction, without balancing


Combined utility function (exponential)
Parameter a = 1, b = 0.5 and c = -1
kj = 1 for all j

This produces the following function values of utilities f(Uij)


Zone
1

180

1
0,37

2
0,43

3
0,41

4
0,39

PTV AG

Chapter 3.2: Demand modeling procedures

2
3
4

0,41
0,41
0,37

0,43
0,39
0,43

0,37
0,41
0,41

0,43
0,43
0,39

Q 1 Z 1 f ( U 11 )
and so F 11 = -----------------------------------------n

i = 1 Qi f ( Ui 1 )

10 50 0.37
F 11 = ----------------------------------------------------------------------------------------------------------------10 0.37 + 20 0.41 + 30 0.41 + 40 0.37

F11 = 4.71
The matrix is produced after the other 15 equations have been calculated.

Result matrix

Zone numbers
1
50.00

*
*

99.98

2
10.00
9.68
4.71
1.03
20.47
10.58
2.06
31.09
15.87
2.80
38.74
18.84
4.11

3
19.99

4
19.99

2.04

1.90

3.64

4.19

6.13

6.29

8.18

7.61

The desired values for destination demand were very well approximated, while the values for
origin demand were not reached so well. This circumstance is characteristic for such
distribution formulas. Either the origin or the destination sums are reached close enough. If
both boundary sums are to be aligned as closely as possible, it is necessary to use a boundary
compensation model. The function offers doubly constrained projection (Multi-Procedure) (see
"Projection" on page 188).

Example 4: Gravity model singly-constrained for attraction, with balancing


Now the trip distribution in Example 3 (see "Example 3: Gravity model singly-constrained for
attraction, without balancing" on page 180) shall be calculated using a balancing procedure
(Multi-procedure).

Input file impedances

* Zone numbers
1
2
1.00
0.50
0.33
0.50
0.33
0.25
1.00
0.50

3
0.33
1.00
0.33
0.33

4
0.25
0.50
0.50
0.25

Input data

* ZoneNo
1
2
3
4

Productions
10
50
20
10
30
20
40
20

Attractions

The parameters are set as follows:

PTV AG

Direction of the distribution according to the production distribution with boundary sum
balancing enforced by the multi procedure.
Combined utility function (exponential)

181

Chapter 3: Demand model

Parameter a = 1, b = 0.5 and c = -1


Scaling according to mean value of both sums
Max. number of iterations = 10, Quality factor = 3
Result matrix

Zone numbers
1

3.2.6

1
50.00

*
*

2
10.01
10.01
4.87
1.06
20.00
10.34
2.01
30.00
15.32
2.70
40.00
19.47
4.24

3
20.00

4
20.00

2.11

1.97

3.55

4.10

5.91

6.07

8.43

7.86

100.01

Iteration
Iteration allows the repetition of the different steps of a procedure and therefore can be used to
re-incorporate skims calculated during the assignment into previous stages.

3.2.6.1

Go to procedure

Use the Go to procedure to carry out a convergence check. You can choose between the
following checks
1. It is checked whether, during the last iteration, attribute or matrix data has changed by less
than the user-defined threshold value. To find the values that have changed, the following
formula is used:

ABS ( X ( n ) X ( n 1 ) ) > MIN ( a M AX ( X ( n ), X ( n 1 ) ) + b, c ) )


with
a
b
c

factor of relative deviation


tolerance value
absolute value for maximum change

The following figure shows how the tolerance value is applied. For smaller attribute values, it
allows for acceptance of larger relative deviations than for larger attribute values. In
illustration 55, the green curve represents the relative deviation, whereby the tolerance value
was considered part of the attribute value.

182

PTV AG

Chapter 3.2: Demand modeling procedures

Illustration 55: Application of tolerance value in Go to procedure

2. It is checked whether a user-defined attribute lies under a specific value. This is useful
when you first add a script that recalculates the respective value.
If the convergence condition has been fulfilled, Visum continues with the next step of the
procedure. If not, Visum returns to the point specified as Go to target (procedure or group) and
iterates the procedure from there (procedure) or from the next step (group). Independent of
this, the convergence check is canceled as soon as a maximum number of iterations is
reached.

3.2.6.2

Method of successive averages over matrices

Using MSA (method of successive averages), you can calculate the mean value of two
matrices (demand or skim matrices).
This function is meant to improve convergence in demand models used for feedback. You can
add it prior to the Go to procedure if you want to use an averaged matrix of all iterations
instead of a matrix of the current iteration as a GoTo criterion.
The operation calculates

i
1
A = ----------- B + ----------- C
i+1
i+1
whereby

A
B
C
i

Result matrix
Matrix of current iteration
Matrix average of all previous iterations
iteration counter

Notes: The iteration counter starts counting from iteration 0 and when Go to procedures are
triggered it always uses the innermost loop as point of reference.

PTV AG

183

Chapter 3: Demand model

3.2.6.3

Method of successive averages over attributes

As for matrices the average values of attributes can be determined by means of MSA (Method
of Successive Averages), too.
This function is meant to improve convergence in demand models used for feedback. You can
add it prior to the Go to procedure if you want to use the average values of attributes of all
iterations instead of the attribute values of the current iteration as a GoTo criterion.
The operation calculates

i
1
A = ----------- B + ----------- C
i+1
i+1
whereby

A
B
C
i

newly calculated attribute value


Attribute value of current iteration
Averaged attribute value of all previous iterations
iteration counter

Notes: The iteration counter starts counting from iteration 0 and when Go to procedures are
triggered it always uses the innermost loop as point of reference.
During an operation you can exchange the two weightings.

3.3

Displaying and editing matrices


Visum provides various options for displaying and editing matrices or using them for
calculations.
Functions used to display and analyze matrices
Highlighting matrix sections in color
Showing matrix values in an aggregated form
Filtering matrix values
Displaying matrix values as a histogram
Comparing matrices graphically in pairs

Visum offers both simple and more complex operations for editing and calculating matrices.
Most operations can be performed directly in the Matrix editor (see User Manual, Chpt. 3.3,
page 823), others are available as procedures (see User Manual, Chpt. 4, page 937).
Functions for copying / replacing matrix values

184

Matrix editor
window

Procedure

Edit individual matrix values interactively

Set values conditionally

x*

Form constant matrix

x*

PTV AG

Chapter 3.3: Displaying and editing matrices

Functions for copying / replacing matrix values

Matrix editor
window

Procedure

Transpose

Reflect upper or lower triangle

Set diagonal

x*

Copy diagonal to clipboard


Paste diagonal from clipboard

Arithmetic operations on matrices

x*

Matrix editor
window

Procedure

Round

Add / subtract matrices

x*

Multiply / divide matrices (element-wise)

x**

Form reciprocal (element-wise)

Raise to power (element-wise)

x**

Take logarithm (element-wise)

Exponential function (element-wise)

Forming maximum or minimum

Symmetrize matrix (calculate average values pairwise from top and bottom
triangle)

Combination of matrices and vectors

Projection: various procedures

Projection of aggregated areas

Calculate matrix using marginal totals, i.e. trip distribution (see "Gravity
model calculation" on page 174)
Generate main zone matrix, using zone matrix (aggregate) - and
generate zone matrix, using main zone matrix (disaggregate)

x
x

* Not a procedure of its own, but possible via Combination of matrices and vectors
** Possible in procedures via add-in CalculateMatrix
Functions for structural changes to matrices
Extend matrix (include new OD pairs in matrix for arithmetic operations)
Aggregate (summarize rows/columns of a matrix)
Split/Extend (rows/columns of a matrix into/to several ones)
Form partial matrix (non-symmetric aggregation)

3.3.1

Displaying matrices in tabular form


There are different ways to organize matrix data in a clear way. In Visum, in the Matrix editor
window, you can change the data display to gain a better overview of your data (see User
Manual, Chpt. 3.3, page 823):

PTV AG

185

Chapter 3: Demand model

3.3.2

You can show matrix data in the matrix or list view.


You can open several matrices in a window so that the corresponding values of the
matrices are positioned side by side.
In addition to the matrix values, it is possible to display the row and column headers as well
as the row and columns totals.
You can change the alignment of the values and the number of the displayed decimal
places.
You can classify the matrix values and display the values of different classes in different
font and background colors.
You can filter the matrix data by active zones, pairs of zones or by specific matrix values,
so that only the rows and columns of your choice are shown.
You can use aggregate functions to show the matrix data aggregated according to
attributes of origin or destination zones, without having to change any data manually.
You can save filtered or aggregated matrix data as a file and continue to use it in Visum as
an external matrix.

Displaying matrix values as a histogram


This function allows you classify the values of one or several matrices and to display them as
column chart. You define intervals for the classification of the matrix values. You can determine
the intervals interactively or import them from a file (see User Manual, Chpt. 3.3.13, page 854).
It is also possible to classify the matrix by using a comparison matrix that must include identical
zones. The OD pairs are divided into the defined intervals based on the comparison matrix.
The matrix values of the input matrix will then be summarized per interval according to this
allocation.
In addition to the histogram a list is displayed showing the number and the percentage of OD
pairs for both, each interval and cumulative for all intervals. If the matrix is changed, the results
will be updated automatically.
This function serves for analyses of existing data for further matrix processing steps, for
example aggregating data (see "Aggregating matrix objects" on page 192). The intervals can
be stored and used for other applications.

3.3.3

Comparing matrices graphically in pairs


In a special window, you can have the data of two matrices displayed along the x and y axis of
a scatter plot. The plot further contains a diagonal, the regression line and the parameters of
the regression function. The shape and position of the point cloud show similarities and
deviations between the matrix values (see User Manual, Chpt. 3.3.14, page 857).

3.3.4

Transpose, reflect upper or lower triangle, apply mean value


The Transpose function allows lines and columns of a matrix to be interchanged, which means
that the values of the rows become the values of the columns and vice versa. The resulting
matrix consequently contains the values of the opposite direction of the input matrix, with
unchanged values in the diagonal. This function is used, for example, to generate a matrix of
the outgoing traffic from a matrix of the incoming traffic (see User Manual, Chpt. 3.4.9,
page 873).

186

PTV AG

Chapter 3.3: Displaying and editing matrices

The Reflect lower triangle function offers the option of copying the matrix section below the
diagonal into the upper triangle (see User Manual, Chpt. 3.4.8, page 872). The Reflect upper
triangle function offers the option of copying the matrix section above the diagonal into the
lower triangle (see User Manual, Chpt. 3.4.7, page 871).

3.3.5

Copy, paste and apply diagonal


Note: The diagonal of a matrix runs from top left to bottom right (FromZoneNo = ToZoneNo).
In demand matrices the diagonal represents the trips within the cell.
The functions Copy diagonal into clipboard and Paste diagonal from clipboard enable the
exchange of diagonal values between two matrices. For example, you can set a matrix value
outside the diagonal to zero by copying the diagonal, setting all matrix values to zero and
reinserting the diagonal (see User Manual, Chpt. 3.4.5, page 869).
The function offers the option of setting the values of the diagonal with a new value, with the
matrix values remaining unchanged for all relations FromZoneNo ToZoneNo.

3.3.6

Round
With the Round function you round all matrix values to a specified precision. The matrix values
are rounded up or down so that the new value is a multiple of the value rounded. Therefore, it
is possible to round up to 0.1 or 0.25, for example (see User Manual, Chpt. 3.5.1, page 875).

3.3.7

Form reciprocal, raise to power, take logarithm, exponential function


The Reciprocal function offers the possibility of transferring the reciprocal of any given matrix
value into the matrix (see User Manual, Chpt. 3.5.6, page 884).
The Raise to power function offers the possibility of giving an exponent for all matrix values and
transferring the result in each case as the new matrix value (see User Manual, Chpt. 3.5.7,
page 885).
The Take logarithm function offers the possibility of determining the logarithm for each matrix
value and transferring the result in each case as the new matrix value (see User Manual, Chpt.
3.5.8, page 887).
The Exponential function offers the possibility of using each matrix value as exponent for e (e
= 2.71828183) and transferring the result in each case as the new matrix value (see User
Manual, Chpt. 3.5.9, page 888).

3.3.8

Maximum or minimum formation


The formation of a maximum or minimum results from the comparison of each value in the
processed matrix with a user-defined value or the matrix value of the same relation in another
matrix (see User Manual, Chpt. 3.5.10, page 890) and (see User Manual, Chpt. 3.5.11,
page 891).
The result matrix then contains the following values for each relation.

PTV AG

The greater of the two values at maximum formation


The smaller of the two values at minimum formation

187

Chapter 3: Demand model

Maximum or minimum formation is mostly used for symmetrization of a matrix, often in


connection with Transposing (see "Transpose, reflect upper or lower triangle, apply mean
value" on page 186).

3.3.9

Make symmetrical: mean value upper / lower triangle


The Make symmetrical function calculates the mean value from the matrix values by element
in the upper and lower triangle and replaces them by this mean value (see User Manual, Chpt.
3.5.12, page 893).

3.3.10

Calculate the combination of matrices and vectors


Values which result from a combination of other matrices and vectors can be assigned to a
matrix. The values of individual input matrices and vectors can be transformed by element,
multiplied by a factor and then added (see User Manual, Chpt. 3.5.13.1, page 894).
Note: This function allows you to add exponential or Box-Cox transformed complex terms.

3.3.11

Defining matrices as formulas


Similar to formula attributes, matrices (see "Formula attributes" on page 104) can be defined
as formulas. Using a combination of matrix and vector expressions, you can define a term that
is automatically updated when changes are made to matrix data or zone attributes. This way,
the matrix is always displayed with its current values. The data in formula matrices is only
readable (see User Manual, Chpt. 3.3.4.2, page 834).

3.3.12

Projection
The functionality is primarily used if origin or destination total values of a zone are to be
multiplied by a particular value, or a particular expected value is to be attained, which can be
necessary in some circumstances after origin-destination studies. Matrices collected are often
just random samples and must be projected to census values.
Matrix values can be projected per row (singly constrained projection regarding the
generation), per column (singly constrained projection regarding the production) or by row and
column (doubly constrained projection) (see User Manual, Chpt. 3.5.14, page 896).
Singly constrained projection means that each row or column is multiplied by a fixed value.
This value can be a procedure parameter or for zone and main zone matrices an attribute
of the zone or main zone. The complexity of doubly constrained projection is illustrated in the
example below.
Objective: projection of origin and destination demand as follows:

188

zone 1 by 10 %
zone 2 by 20 %

PTV AG

Chapter 3.3: Displaying and editing matrices

Zone

Origin traffic

20

30

50

40

50

90

Destination traffic

60

80

140

Table 45: Basic matrix

Line by line multiplication, therefore for purely singly constrained projection of the demand
regarding production originating from zone 1 by 10% and zone 2 by 20%, produces the
following matrix.
Zone

Origin traffic

22

33

55

48

60

108

Destination traffic

70

93

163

While the origin traffic has been increased correctly, the destination traffic has not.
For the doubly-constrained projection, the Matrix editor uses an iterative process, also called a
Multi-procedure. In an iterative progression, this process searches for the solution that best
achieves the expected values (see "The multi-procedure according to Lohse (Schnabel 1980)"
on page 189).
The Matrix Editor thus provides the following solution which correctly projects the origin and
destination traffic.
Zone

Origin traffic

21

34

55

45

62

107

Destination traffic

66

96

162

Table 46: Result matrix

The multi-procedure according to Lohse (Schnabel 1980)


With the multi-procedure new traffic flows are calculated in each iteration step Fij (Schnabel
1980).
The iteration formula applied is as follows

Fij(n+1) = Fij(n) qi(n) zj(n) f(n)


with

Q ip
q i ( n ) = -------------------------------Z jp
j Fij -----------Zj ( n )

PTV AG

189

Chapter 3: Demand model

Z jp
z i ( n ) = --------------------------------Q ip
i Fij ------------Qi ( n )
Gp
f ( n ) = ----------G(n)
Qip

Desired origin traffic zone i

Zjp

Desired destination traffic zone j

Gp

Desired total traffic

Fij(n)

Traffic flow from zone i to zone j in iteration n

Qi(n)

Origin traffic zone i, iteration n

Zj(n)

Destination traffic zone j, iteration n

G(n)

Total traffic, iteration n

This iterative calculation is done repeatedly until the following conditions are met for all
boundary values (origin and destination expected values).

Qi ( n )
-------------- 1 for all zones i
Q ip
Zj ( n )
------------- 1 for all zones j
Z jp
The threshold suggested by Lohse was used. It states that
1
1
= ----------------------------- or = ---------------------------( QF Q ip )
( QF Z jp )

QF: quality factor

3.3.13

Projection of aggregated areas


You can also use this function for matrix projection. Contrary to simple projection, you do not
specify a factor per row or column, but the rows and columns of matrices are separated into
groups. You then define a projection factor per group or per relation between the groups (see
User Manual, Chpt. 3.5.15, page 900).
Thereby you need to distinguish between two modes:

Singly constrained projection by territory: This largely corresponds to singly


constrained projection (see "Projection" on page 188). The only difference is that for
projection by territory the rows or columns of the matrix are separated into groups ("areas")
and you specify a projection factor per group.
Projection by item: For this procedure the projection factors are not defined per row or
column, but per row/column relation. Here the rows and columns are also separated into
groups and you specify a projection factor per "group relation".

If you are using a matrix with network references, i.e. a zone or a main zone matrix, you can
choose an attribute of the zone or main zone to separate the rows and/or columns into groups.

190

PTV AG

Chapter 3.3: Displaying and editing matrices

If in this case, you e.g. select the attribute Main zone number for a zone matrix, singly
constrained projection will use a specific factor per main zone for projection. Projection by item
would use a different factor per main zone relation.
Note: The term "territory" used here merely describes a group of rows or columns and is not
to be confused with the network object of the same name.

3.3.14

Converting zone and main zone matrix into each other


When calculating the main zone matrix from a zone matrix, you add the matrix values of zones
that belong to the same main zone. This applies both to OD demand and skim matrices. The
total amount of the matrix values are added to the main zone matrix, the zone matrix is kept.
When disaggregating a main zone matrix you divide the matrix values of the main zones into
several matrix values for the individual zones and add them to a zone matrix. The values can
be equally distributed. However, you can also weight them. As weighting factors you can use
the values of one or two zone matrices or of OD zone attributes.
If you select two weighting factors, the new matrix values are calculated as follows:
(1)

b ij

(2)

w ij w ij
= ------------------------------------------------------------------------------------------------- a IJ
(1)
(2)
w kl w kl

k Index ( I )

l Index ( J )

whereby

i, j
i, j
Index(I), Index (J)
bij

Zone indices

aij

Value in input matrix (main zone matrix)

wij(1), wij(2)

two weighting factors

Main zone indices related to the zone indices


Number of zone indices belonging to the main zone
Value in the output matrix (zone matrix)

Note: If the denominator of a fraction is zero, weighting will be ignored.

Use case
You would like to correct a matrix or adjust it using count data. The count data available refers
to a rougher zone structure than your network. In this case, you first aggregate the zone
matrices, then perform a correction procedure (e.g. TFlowFuzzy) and finally disaggregate the
matrix again.

3.3.15

Extending matrices
You can extend external matrices during an arithmetic operation, i.e. you can add columns and
rows. To do so, choose an arithmetic operation that allows you to combine external matrices
with matrices that have different OD pairs.
You can use any arithmetic operation that requires a second operand, e.g. the basic ones or
forming the maximum or minimum.
The matrix data is calculated as follows:

PTV AG

191

Chapter 3: Demand model

The arithmetic operation is performed for the OD pairs that occur in all matrices.
If an OD pair is not listed in all matrices, a null is entered for it before the arithmetic
operation is performed. Then the arithmetic operation is performed.
For OD pairs that are not listed in any of the matrices, a default value is set in the results
matrix.

Example of extending a matrix


On the addition, the two matrices are extended. The standard value specified for new OD pairs
is 99.

Matrix in Matrix editor window


1

Matrix chosen as operand

3.3.16

Matrix extended on addition


1

99

99

99

99

Aggregating matrix objects


This function allows you to group several matrix objects to create one or several new objects.
You can use the Aggregate function to rename zones and/or group them into larger units (e.g.
districts). The number of rows and columns of a matrix is changed through aggregation.
The new matrix values are calculated with the aid of the following formulas:
Arithmetic mean

i = 0 qi

--------------------n

192

PTV AG

Chapter 3.3: Displaying and editing matrices

Weighted mean

i = 0 qi gi

-----------------------------n

i = 0 gi
with

qi

Matrix value of ith zone

gi

Weighting of ith zone

Number of columns or rows

Example of aggregating matrix objects


The matrix values of the matrix below are aggregated.

Zone allocations and settings:

Zone 10 is removed from the matrix


Zones 20 and 30 are aggregated and will form the new zone 39
The weighted mean is used as aggregation function.
The matrix data is weighted using the following matrix.

Origin and destination zones of the matrix are aggregated


The matrix values of the original matrix are used

The following matrix results.

Matrix values of destination zone 39 were calculated as follows:


6 6 + 7 7 + 1 10 + 1 11- = 7.1
--------------------------------------------------------------------6+7+1+1
14
2 + 15 2- = 14.5
---------------------------------2+2

PTV AG

193

Chapter 3: Demand model

3.3.17

Splitting (extending) matrix objects


Using the Split function, you can subdivide zones into smaller units. The number of rows and
columns of a matrix is changed through splitting. This function is often used for adapting overall
demand matrices to a finer zone classification in the network model.

If you only specify one factor for an object generated during splitting, this factor applies to
both the source and destination traffic in the demand matrix.
If origin and destination value are to be distributed with different proportions in a zone
generated by splitting, a destination traffic factor must also be specified after the origin
traffic factor.

For a demand matrix, the matrix value is generally distributed across the zones (1.0 = 100 %)
created through splitting. When choosing the splitting factors for zone generation, you can
decide whether or not you want to include the expected gains (total > 1.0) or losses (total < 1.0)
per split zone.
For a skim matrix, the matrix value per split zone is generally assigned to the new zones using
the factor 1.0, i.e. they remain unchanged.

Example of splitting matrix objects


The zones of the following matrices are split and deleted.

Thereby the following settings are made:


Zone number old

Zone number new

Factor origin traffic

Factor destination traffic

100

1,001

0.3

0.1

100

1,002

0.5

0.2

100

1,003

0.2

0.7

200

2,001

0.7

0.7

200

2,002

0.3

0.3

In addition, all trips created within the cell are set to null.
This produces the following matrix:

Total of matrix data for all OD pairs from/to 1,001..1.,003 equals 1,000.

194

PTV AG

Chapter 3.4: Matrix correction

3.4

Matrix correction
You have different possibilities of correcting the demand matrix values with count data.

3.4.1

Updating demand matrix with TFlowFuzzy


Projecting PrT path volumes
Calibrating a PrT matrix

Updating demand matrix with TFlowFuzzy


Like all matrix correction procedures, TFlowFuzzy is meant to adjust a demand matrix, so that
its assignment results for a supply actually match the real supply observed (source/target
traffic, passenger trips unlinked or number of boarding/alighting passengers). This procedure
can be useful in several situations:

A demand matrix based on empirical survey data is outdated and you want to update it
without having to conduct a new (origin-destination) survey. The update shall be based on
based on census data only.
A matrix generated from the transport network model is to be calibrated, therefore counted
volume data are to be used.
A matrix generated from incomplete or not reliable data is to be improved by more
comprehensive/reliable volume data counted simultaneously.
A survey contains the journey distance distribution, but the model does not reflect the data
with the level of accuracy required.

TFlowFuzzy will solve this problem for PuT as well as for PrT. The update only affects the
demand matrix - not the time series - and always refers to total volumes (instead of volumes
per time interval).
The flow of information always follows the given order.
Old
matrix
data

New
count
data

TFlowFuzzy

New
matrix

The workflow for the matrix calibration is as follows.

PTV AG

195

Chapter 3: Demand model

Count data
Network
model
Assignment

TFlowFuzzy

Demand
matrix

You can choose the following count data:

Link volumes
Origin/destination travel demand per zone
Volumes of turns at nodes and main turns at main nodes (as long as they are defined)
Volumes via screen lines
Volumes on lanes
PuT passenger trips unlinked per line
PuT passenger kilometers per line
Boarding/alighting passengers at stop areas
Skim data distribution, e.g. journey distance distribution

You can also combine count data.


A detailed example of how to use journey distance distribution is available in the folder:
...\Users\Public\Public documents\PTV Vision\PTV Visum13\Training\TFlowFuzzy.
It is best to work with volumes on lanes if you want to use count data that comes from stop line
detectors. These are - other than manually collected node flows - not already assigned to a
(main) turn, but to the lane the detector is located on. If you are using lane counts, you need to
model the lane allocation at the respective node in the Junction editor. Visum aggregates lane
counts to counts per lane group, i.e. the count data is added across all (main) turns that have
at least one shared lane. TFlowFuzzy compares the count data sums to the volumes of all
routes that use this lane group.
Sometimes PuT passengers alighting/boarding at stop areas are counted separately for each
direction. To be able to use the information content of the disaggregated count data, without
having to separate the stop area into several parts, separate the line routes traversing the stop
area into groups. Then specify count data and tolerances for each group.
For the update, the specified count values are compared with the volumes, which result from a
pre-calculated assignment of the previous demand matrix. Differences between count values
and volumes are balanced by adjustment of the demand matrix for the assigned demand
segment. The simplest case refers to a single demand segment. The volumes from the

196

PTV AG

Chapter 3.4: Matrix correction

selected network object are then taken from the assignment result of this demand result, and
the count values also only refer to this demand segment. TFlowFuzzy can also simultaneously
update the demand matrices of several demand segments, if only total count values are
specified for all demand segments. Then the count data specified is distributed proportionally
to the respective demand segment share of the assignment volumes. The demand matrix for
each demand segment is then updated individually.
Compared to other procedures, the outstanding quality of TFlowFuzzy is

that you can combine the following for matrix correction: origin/destination traffic, link
volumes, turns, main turns or screen lines, passenger trips unlinked and passengers
boarding/alighting at stop areas and distributions (e.g. journey distance).
Count values do not have to be available for all network objects.
The statistical uncertainty of the count figures can be modeled explicitly.
You can specify that the distribution of the result matrix must correspond to the distribution
of an existing demand matrix.
You can use count data that only covers part of the PuT lines. In this case, only volumes or
boarding/alighting passengers that refer to active line route elements are taken into
account for calculation.

3.4.1.1

Methodological basics of TFlowFuzzy

Since the eighties, primarily in English-speaking countries, so-called matrix correction (or
matrix update) techniques have been used to produce a current demand matrix from an earlier
travel demand matrix (base matrix) using current traffic count values. Based on research by
Van Zuyten/Willumsen (1980), Bosserhoff (1985) and Rosinowski (1994) which focuses on
matrices for private transport, PTV has extended the application of these techniques to public
transport.
The starting point for the classic procedure is the travel demand for the individual OD pairs fij.
Travel demand is usually described as a matrix, but for our purposes a vector representation
containing all non-zero OD trips is more suitable.

0
f 21
f 31

f n1

f12
0
f32

f n2

f13
f 23
0

f n3

f1n

f 2 n
f 3n =

0

f12
f13

f1n
f 21
f 23


f 2n
f 31

While it is usually assumed, that a matrix based on an earlier time is known, only partial
information is provided for the current state. Important is the situation where there are no data
based on relations (from an origin destination survey) available, but only count values at
individual positions in the network. These can be both origin / destination traffic as well as link
volumes. We note the count values as another vector.
v r = (v1 v2
PTV AG

v3 vm )
197

Chapter 3: Demand model

The trips of any OD pair provides a certain share to each traffic count. In case of boarding and
alighting passengers the marginal sums of the demand matrix are known. In case of link counts
the counted volumes correspond to the sum of all (proportional) OD trips traveling on this link.
In general there is a linear relation between the demand on the OD pairs and the traffic counts.
Af=v

whereby A is called flow matrix. ask is "the share of passengers on movement k, traversing link
s". For origin / destination traffic count values, A is especially constant, as specified with
example n = 3, m = 6.
1

0
0

1
0

1 0 0 0 0 t12 board1

0 1 1 0 0 t13 board 2
0 0 0 1 1 t21 board3

=
0 1 0 1 0 t23 alight1

0 0 0 0 1 t31 alight2
1 0 1 0 0 t32 alight3

In this case, A does not depend on the timetable. However, the supply dependent trip choice
flows into A for link volumes; the flow matrix is obtained for example, through assignment of
any matrix (for example the old demand matrix) on the supply at the time of the count. Both
types of count values can be also be used next to each other without a problem.
A problem for the matrix correction is that, usually m << n2 and therefore the new matrix is
underdetermined by the count values. Out of the countless matrices which match the count
values "match", only the best is selected according to a evaluation function q, thus solves
max q(f), so that A f = v
A combination of entropy and weighting with the proportions of the old matrix usually serves as
an evaluation function; q is usually non-linear, which is why the problem is solved iteratively (for
example with Newton's method).
In this wording of the matrix correction problem there is, however, another weakness of the
classic approach: vector v of the count values is assumed as a known parameter, free of every
uncertainty. A q maximum is only selected from the matrices which fulfill the exact secondary
conditions. The count values thus receive an inadequate weight, because each survey
provides a snap shot, which is afflicted with a statistical uncertainty. Conventional procedures
(for example from Willumsen) do not allow such a state, because the boundary sums are
perceived as "strict" secondary conditions.
PTV has therefore taken on the approach by Rosinowski (1994), who modeled the count
values as fuzzy measured data according to the Fuzzy Sets Theory. If it is known that in a
zone, the origin traffic fluctuates up to 20 % from day to day, in other zones however about
25 %, this is illustrated with the respective bandwidths. In the secondary conditions of the
matrix estimation problem, there are thus Fuzzy Sets ~
v s with sets of variables of different
widths which replace strict values.
max q(f), so that A f = v

198

PTV AG

Chapter 3.4: Matrix correction

The illustration of Fuzzy Sets compared to pure limits allows the preference of central values
to be expressed within the set of variables. This means, that values close to the mean values
are generally preferred, but values within the margin are also accepted, if this means that a
much better q value is achieved.
How can the Fuzzy Sets now be treated numerically for the solution of the optimization
problem? The obvious trip is, to include the membership function of the individual Fuzzy Sets
in the evaluation function and in comparison weighted appropriately. To be able to continue
using standard procedures of non-linear optimization, the resulting objective function must also
be twice continuously differentiable, producing restrictions regarding the form of membership
functions. Especially the usually partial linear triangles or trapezoids are eliminated. Instead we
use the same mechanism as for the weighting with the original matrix, to support the choice of
central values from the set of values. As a comparison, here the evaluation function of the
weighted entropy maximization.

q( f ) =

n n

f ij

f ij ln f ij
f ij
i =1 j =1

If f ij is already set as a demand from the original matrix, the maximization of q benefits
matrices which slightly differ from the original matrix. This principle can be transferred to our
new optimization problem:
max q(f, s, s), so that
Af+s=v
A f - s = v
s0
s 0

where v ,v = maximum or minimum of the set of variables of the Fuzzy Sets.


If the slack variable s, s is included in the weighted entropy maximization s = s = 0 , matrices
are favored that fulfill A f = v "best". Doubling the equation appears to be a disadvantage,
because this has a direct effect on the calculation time of the runtime determining Gauss
method within the Newton iteration. Symmetries in the resulting equation system however, still
only allow to solve a system half the size and hence, deduct a solution of the entire system.
The range of solutions of the estimate problem increases due to the Fuzzy formulation and
therefore the degree of freedom for the evaluation (here: entropy maximization), so that
generally higher target function values can be achieved. To make it clearer, the "most likely"
demand matrix is thus estimated, which represents the count values within the bandwidths.

Illustration of Fuzzy sets with an example


A Fuzzy set is generally defined as a set of possible values (set of variables) and a
membership function with values between 0 and 1, which specifies "how much an element of
the set of values is perceived as related to the fuzzy set". If the membership function is 0, the
element does not belong to the unclear set. For a value of 1, element "total" belongs to the set
and interim values express the quality of approximation. If for example, you want to express the
value "approximately 4" as a fuzzy set, the set of variables could contain the interval [3;5] and
the membership function rises from value 0 to the interval margins to a maximum of 4.
PTV AG

199

Chapter 3: Demand model

Membership
function

0
3

To make bandwidth modeling in TFlowFuzzy more manageable and operation easier, it is


assumed that the membership function has a very special form. From value 1, which is
assumed by the survey count values, it drops symmetrically to both sides. It thus creates a
triangle, which is determined through the following values.

Membership
function

0
z-*s

z
s

z+*s

the count value itself, where the membership function assumes its maximum
the distance between the count value, where the membership function drops to value 0
a predefined scaling factor ( > 0)

Values z, s and are entries for TFlowFuzzy (see User Manual, Chpt. 3.7.1, page 910). z and
s are specified individually for each count value (link volume, origin / destination traffic, turn
volume or main turn volume, as long as a main node is defined), whereas is a global
parameter for the procedure.

3.4.1.2

Numeric example for TFlowFuzzy

A calculation example is used to illustrate the matrix correction procedure. A PuT service is
defined in the very simple network with four zones shown here.

200

PTV AG

Chapter 3.4: Matrix correction

The link bars show the assignment result for the following matrix, which we assume were
obtained a long time ago by means of a passenger survey:
$VR
* PTV
* Time interval
0.00
24.00
* Factor
1
* Mode of transport No. 3
*
3 Mode of transport PuT
*
4 Mode of transport PrT
* Number of zones
4
1
2
3
*Zone
1
Total =
0
100
100
*Zone
2
Total =
100
0
100
*Zone
3
Total =
100
100
0
*Zone
4
Total =
100
100
100

4
300
100
300
100
300
100
300
0

Counts have since been completed on all links of the network, and the following volumes
obtained.

The counted values for this example are based on the assumption that the demand matrix has
since changed as follows.
$VR
* PTV
* Time interval
0.00
24.00

PTV AG

201

Chapter 3: Demand model

Factor
1

* Mode of transport No. 3


*
3 Mode of transport PuT
*
4 Mode of transport PrT
* Number of zones
4
1
2
3
*Zone
1
Total =
0
150
100
*Zone
2
Total =
150
0
100
*Zone
3
Total =
100
100
0
*Zone
4
Total =
100
80
100

4
350
100
330
80
300
100
280
0

The counted values from the figure are loaded into Visum LinkAddValues. Additionally, for
each individual counted value or collectively, a random sample fuzzy value can be added,
which means a bandwidth, within which the counted values actually fluctuate from one survey
date to another. This fuzzy value can be accepted as it is or obtained empirically by counting
the same OD relations on different dates.
TFlowFuzzy now calculates a new matrix, which on the one hand exhibits to a very high degree
similar ratios between the number of trips in the individual OD relations as in the old matrix (by
maximizing the weighted entropy), and on the other hand, during assignment matches the
counted values from the new survey within the specified bandwidth.
In the above example TFlowFuzzy, with a random sample accuracy of 5 %, calculates the
following matrix, which matches the assumed "ideal solution" very well.
$VN
4
*
*

1
346
1:
2:

3:

4:

3
298

4
281

148

99

99

100

83

100

99

83

99

346
0

2
331
331

148
298
99
281
99
* 1256

3.4.2

Projecting PrT path volumes


The Projection of routes command adjusts the demand matrix of a PrT transport system to the
counted data of particular links. Thereby all movements Fij that use a selected link for a PrT
demand segment are projected, so that the link volume corresponds to the count data
(AddValue). The relations used in this process are the result of an assignment in which all used
trips are saved along with their volumes.
The update only affects the demand matrix - not the time series - and always refers to total
volumes (instead of loads per analysis time interval).

202

PTV AG

Chapter 3.4: Matrix correction

3.4.3

Calibrating a PrT matrix


The Cali procedure provides a calibration function that uses count data to calculate projection
factors - based on assignment results - for origin and destination sums of a PrT demand matrix.
Using a balancing procedure the matrix is then projected to the sum values.

3.4.3.1

General principle of the calculation procedure

The projection of the matrix corresponds to the Increase factor model with justification, known
in traffic planning. By comparing the calculated volume with the count data, the counted cross
sections supply information on "adjustment factors" which need to be taken into account. Here
it has to be taken into account that an origin/destination relation can traverse several counted
cross sections, that is, it might be influenced by several adjustment factors.
The calculation process has two stages.
1. Determination of the adjustment factors
First, the calibration function calculates an adjustment factor ki for each count value zi.

These apply to all relevant flow bundles.


This results in modification potentials for all relevant origin and destination traffic.
Since the adjustment factors belonging to a zone might have to be calculated using
different count value adjustment factors zi..n, these factors must be averaged and
balanced.
Adjustment factors for origin and destination traffic are thus generated for those origins
(rows) and destinations (columns) which were found by flow bundles.
Rows and columns which were not found by flow bundles are assigned a mean
adjustment factor determined by the adjustment factors for traffic flow elements.
2. Projection of the matrix using the projection factors generated as explained above

3.4.3.2

Example: Matrix projection

The Fij matrix of the last assignment serves as the basic matrix.
Zone

Origin traffic

20

30

50

40

50

90

Destination traffic

60

80

140

If the traffic of Zone 1 is to be increased by 10 % and the traffic of Zone 2 by 20 %, the following
matrix (for a projection of the origin only) will result:

PTV AG

Zone

Origin traffic

22

33

55

48

60

108

Destination traffic

70

93

163

203

Chapter 3: Demand model

It is clear that, although the origin traffic increased by the required amount, the destination
traffic did not, because
1.1 * 60 = 66 and 1.2 * 80 = 96.
This is why an iterative procedure, the Multi-procedure according to Lohse (Schnabel 1980), is
used for origin and destination projection, as in an iterative process it searches for that one
solution that is best used to reach the target values (see "The multi-procedure according to
Lohse (Schnabel 1980)" on page 189).
For the above example the following solution is found:

204

Zone

Origin traffic

21

34

55

45

62

107

Destination traffic

66

96

162

PTV AG

Impact models
An impact model contains all methods to calculate the impact of traffic. It calculates results on
the basis of data and thus represents the computation kernel of the application. Components
of the different impact models offered in Visum are in particular assignment, skim calculation,
line blocking, line costing calculation (PuT operating indicators) and emission calculation,
including the impedance models used in them. Each of these methods is part of at least one of
the impact models for users, operators and the environment.

Subjects

4.1

The types of impact models


Impedance functions
Paths in PrT and PuT
Skims / indicators

The types of impact models


A transport supply system has diverse impacts which may vary because of measures. Impacts
always refer to those actively or passively involved in traffic, for example the users or operators
of the transport supply system, to the general public or the environment. The impact models in
Visum are differentiated according to those involved and each comprises all methods on
calculating the effects on one of the roles mentioned.

4.1.1

The user model


Users of infrastructure for private transport are mostly car drivers and their passengers, but
also non-motorized travelers such as cyclists and pedestrians. Users of public transport are
public transport passengers. Objective of the user model is to determine the impacts of a
transport supply system on travelers. Important skim data for evaluating the transport supply
are the journey time and traveling expenses between two zones. To evaluate a public transport
supply, additional skim data such as number of transfers, transfer wait time and service
frequency must be considered.
To determine these user-specific skims, the OD trips of travelers are modeled. A user chooses
a route for his trip which appears convenient to him. If in addition to the route, the user also
selects the departure time of his trip, one speaks of a connection independent of the mode. In
addition to the spatial course, a connection thus comprises the entire temporal course: In
public transport especially the departure and arrival times at the boarding stop, at the transfer
stops and at the destination stop and in private transport the selected departure time, the
arrival time and the transit time for each location along the route. If the temporal progression of
the traffic situation has been explicitly modeled in this way, one speaks of a dynamic model
(dynamic assignment). There is no time axis for a static model, however, so that OD trips take
place without temporal course and have a simultaneous effect on each location in the network.
There are static and dynamic user impact models in both PrT and PuT.

PTV AG

205

Chapter 4: Impact models

Methods to model the travel behavior are based upon search algorithms which determine
routes or connections between an origin and a destination. Procedures used as search
algorithms are those which determine the best, meaning those which determine paths with the
lowest impedance or a set of sufficient paths. Impedance can consist of times, distances, and
costs. Depending on the search algorithm used, the paths found represent routes or
connections. The trips by OD pair are distributed among the paths found. This combination of
path search and trip distribution is called assignment. Private transport assignment assigns
vehicle trips; public transport assignment assigns passenger trips.
For every route or connection between two zones skims can be calculated which describe the
service quality of the route/connection. In addition to this, an assignment produces traffic
volumes for links and turns, and in PuT projects also for stops and stop points plus all objects
of the PuT line hierarchy from the transport system down to the level of individual vehicle
journeys. In contrast to a quality skim such as, for example, journey time, the volume is only an
indirect skim which by itself is not suited for evaluating the transport supply system. The
volume is rather used to deduce

saturation of PuT lines which affects the comfort of passengers and the revenues of
operators
noise and pollution emissions which indicate the environmental impact

Thus, the volume resulting from the user impact model serves as a basis for the procedures
provided by the operator impact model and those of the environmental impact model as well.
Visum offers various assignment procedures for private and public transport. They differ by the
search algorithm and by the procedure used for distributing demand. These assignment
procedures are a central part of Visum. There are PrT models and PuT models.

4.1.2

PrT (see "User model PrT" on page 211)


PuT (see "User model PuT" on page 429)

The operator model


Transport supply operators are PuT transport companies and transport associations, in a
broader sense these also include the PuT contractors of the operators. To offer public transport
service, PuT operators develop line networks and timetables from which the user can then
choose connections.
To estimate the impacts on PuT operators, the so-called operator model is used to determine
indicators which describe the operational and financial requirements for offering public
transport supply on the one hand and on the other hand the expected revenues (see "Operator
model PuT" on page 521). The PuT operator model comprises the following methods.

Line blocking which determines the number of required vehicles


Determining operational costs
Estimating revenues
Line costing which distributes the operational costs and revenues over PuT lines

Compared to the PuT, the PrT network is generally operated by the state, countries or councils,
but also more and more by private investors. Decisions are geared towards the impact on the
general public, rather than on the impacts on the operators themselves, which is why in general
a different operator model has to be used for PrT. Here the economical analysis (EWS) impact
model is available in Visum. This model comprises methods on economical return of

206

PTV AG

Chapter 4.2: Impedance functions

investment analysis according to recommendations for economic feasibility studies published


by the German FGSV (Road Traffic Research Association in Germany in 1997) (see
"Economic assessment according to EWS" on page 663).

4.1.3

The environmental impact model


Visum provides three models within the environmental impact model, to calculate the
environmental impacts which are noise and pollution emissions, caused by motorized private
transport (see "Environmental impact model and HBEFA" on page 651).

4.2

Noise-Emis-Rls90: Calculation of noise emission levels in accordance with the guideline


on noise reduction for roads, edition 1990 (RLS-90), without considering immission
parameters.
Noise-Emis-Nordic: Calculation of noise emission levels in accordance with Nordic Council of Ministers (1996).
Pollution-Emis: Calculation of air pollution emissions in accordance with emission factors
of the Swiss Federal Office for the Environment (BAFU).

Impedance functions
An impedance function generally measures the effort connected to a traffic process. All
instances are summarized to this effort, which prevent participants from carrying out this
process and therefore create an impedance. Effort examples are especially time and costs
connected to the process. You can also enter subjective criteria in the impedance. Thus, the
impedance of a certain connection in the PuT may increase, if certain comfort criteria are not
satisfied.
Impedance functions play an important role in several impact models. In the assignment, the
impedance function assigns a route or connection an effort. In PrT, especially the journey time
in the loaded network flows into the impedance, but it can also be additional properties such as
traveling expenses and possible toll. For dynamic assignments, it is also the discrepancy
between the departure time and the desired departure time. In PuT, in addition to the travel
time, it is mainly the number of transfers and the fare which have an effect on the impedance.
A problem for impedance functions is that completely different aspects are included and have
to finally arise from conjoint evaluation in form of a number. These different aspects which are
partially measured in different units, must therefore be recalculated and weighted against each
other. In general, weighting of the factors for different groups of assessing personnel is
different. For this reason, impedance functions for example can be defined at the assignment
per demand segment (see User Manual, Chpt. 5.2, page 977) and at line blocking per vehicle
combination (see User Manual, Chpt. 7.1.3.2, page 1169).
In Visum, impedance functions are used in the following contexts:

PTV AG

Assignment (User model): The impedance function assigns the effort to each path, thus
depending on the type of assignment, each route or connection, which the passenger has
to make, if he decides to take this path. The most natural criterion is the travel time which
has the corresponding unit time [s]. Especially in PrT, the travel time of a link is not
constant, but depends on the volume, the coherence is described in a VD function.

207

Chapter 4: Impact models

Demand models (User model): Within the framework of trip distribution, mode choice, as
well as combined procedures for trip distribution and mode choice, the impedance function
allocates an OD pair or the mode choice for this relation to the effort, which has to be
overcome for this choice. In this context we are traditionally talking about utility functions.
Although the supporting concept is identical, the benefit of it is, however, only the negative
impedance of the process.
Line blocking (Operator model): The impedance function assigns each activity (vehicle
journey, empty trip, layover, etc.) in a cycle the effort which arises, if the activity is
performed by this cycle. The most natural criteria here are the costs.

Despite these different application areas, the impedance function structure is always the same:
Each impedance function consists of a sum, in which each summand evaluates a certain
aspect of the effort and is weighted by a coefficient (see illustration 56). To calculate the
impedance of a traffic process, the properties of the process are first determined regarding
each aspect. Each aspect is then evaluated separately, in PrT especially by evaluating the VD
function. This evaluation of individual aspects is then provided and summed up with the
weighting factors.

Illustration 56: Impedance calculation for a PuT connection, for clarity illustrated in the unit [min]

208

PTV AG

Chapter 4.3: Paths in PrT and PuT

4.3

Paths in PrT and PuT


All assignments in Visum in PrT as well as in PuT are path-based, meaning that possible paths
are calculated for each OD pair and loaded with a demand share. All other results, especially
the different network object volumes and the skim matrices are derived from these loaded
paths. These paths are saved with the assignment result and can be analyzed after the
assignment for flow bundle calculation, for example.
A path first describes the exact local course of a translocation in the network model, which
means, that all traversed network objects such as nodes, links, turns, main nodes,
connections, if applicable also stops, line routes and time profiles are known. If the departure
time and thus the temporal course is added to the spatial course, we are taking about a
connection, otherwise a route. For PuT paths, in addition to departure time for a connection
compared to the route, the information on used vehicle journeys is included.
If an assignment produces routes or connections depends on the type of assignment. Dynamic
PrT assignments and the timetable-based PuT assignment create connections, static PrT
assignments as well as the headway-based PuT assignment calculate routes. In principle, the
user can select, whether internally calculated connections should be saved as such or only as
routes, or not at all respectively for PrT (see User Manual, Chpt. 5.1.2, page 975) and PuT
(see User Manual, Chpt. 6.1.1.2, page 1072). If you do not save the connections, less memory
is required, however, posterior analyses of the connections are no longer possible, even if a
dynamic assignment procedure was applied. Network volumes are still calculated and can
even be output differentiated according to analysis time intervals.

4.4

Skims / indicators
A skim is a measurement taken from the traffic model. Typical examples are the mean travel
time from a zone A to a zone B, which is calculated from the travel times of all paths found, as
well as the total PuT journey time, which is the sum of the journey times of all PuT passengers.
Skims can be divided into global skims, which describe properties of the entire traffic model,
and into skims gained per OD pair. The latter are stored in skim matrices, whereby the entry xij
for the skim value, refers to the relation from zone i to zone j.
Generally, skims measure the properties of the traffic model. In feed back models they are also
the input data for the demand modeling procedures, especially for trip distribution and mode
choice.

4.4.1

Skim matrices
Skim matrices describe properties of each relation from an origin zone A to a destination zone
B in the traffic model. Each individual skim (for example the travel time in a vehicle) is extracted
from the path properties from A to B, which belong to a demand segment. The skim data is then
aggregated with the relative share of demand, which the path would attract, to a skim value for
the OD pair. This also applies, if there is no demand for the relation from A to B, because
distribution does not depend on the demand.

PTV AG

209

Chapter 4: Impact models

The calculation of skim matrices differs between PrT and PuT on some points. The calculation
of PrT skim matrices is either based on present paths from a previously calculated assignment,
or for each OD pair the optimum path with regard to the impedance is determined (in the
possibly loaded network). Compared to an assignment, the network is not loaded in this case.
Because in this case there is only one path per relation, the skim value is extracted directly
from this path. If, however, paths from an assignment are used for skim matrix calculation, the
value of the minimum or maximum path impedance can be output as skim value, or the
weighted or unweighted mean value calculated from all paths by OD pair.
In PuT always more than one route or connection is calculated per OD pair, and the skim value
is derived from these. In addition to the average determination, optionally weighted with the
demand share, the output of properties of the path with the least perceived journey time (PJT,
timetable-based procedure) or with the least impedance (headway-based procedure) as well
as quantiles are available as additional aggregate functions. The skim is especially directly
dependent on the applied search strategy. Because not only the saved, but all paths found are
included in skim matrix calculation, the result differs from the result subsequently derived from
the paths. This is the case, if the demand becomes zero on some paths by an explicitly
requested rounding and the path is therefore not saved, but used for skim matrix calculation. If
demand and volume rounding is switched off, such differences cannot occur.

4.4.2

Global indicators
In addition to the skims by OD pair and demand segment, which are available in skim matrices
and are only calculated on demand, Visum automatically calculates a specified set of global
indicators with each assignment. These are properties of the overall assignment result, i.e., of
the traffic model itself. Typical values are the mean travel time in the network, the total vehicle
impedance in PrT, the total journey time of all PuT passengers, as well as the number of
passenger trips by PuT line. The global values are displayed via lists (see "Evaluation lists" on
page 731).
If several assignments are carried out subsequently, the global values represent the properties
of all paths in these assignment results. Compared to the skim matrices, these values orientate
themselves towards the loaded paths contained in the result. They are thus consistent with
properties of the saved paths.

210

PTV AG

User model PrT


The User model PrT calculates the effect of the private transport supply on all car drivers and
passengers, but also on non-motorized road users such as cyclists and pedestrians.

Subjects

5.1

Overview of the PrT assignment procedures


Example network for the PrT assignment procedures
PrT Paths
Impedance and VD functions
Impedances at node
PrT skims
Distribution of the traffic demand to PrT connectors
Blocking back model
Convergence criteria of the assignment quality
Distribution models in the assignment
Incremental assignment
Equilibrium assignment
Linear User Cost Equilibrium (LUCE)
Equilibrium_Lohse
Assignment with ICA
Stochastic assignment
TRIBUT
Dynamic User Equilibrium (DUE)
Dynamic stochastic assignment
NCHRP 255
Assignment analysis PrT

Overview of the PrT assignment procedures


Visum provides several assignment procedures for the PrT. There are static assignment
procedures without explicit time modeling as well as procedures which use a time dynamic
traffic flow model.

PTV AG

The Incremental assignment divides the demand matrix on a percentage basis into
several partial matrices. Then, these partial matrices are successively assigned to the
network. The route search considers the impedance which results from the traffic volume
of the previous step (see "Incremental assignment" on page 315).

211

Chapter 5: User model PrT

212

Equilibrium assignment distributes the demand according to Wardrop's first principle:


"Every road user selects his route in such a way that the travel time on all alternative routes
is the same, and that switching to a different route would increase personal travel time."
The state of equilibrium is reached through a multi-step iteration process based on an
incremental assignment as the starting point. In the inner iteration step, two routes of a
relation are brought into a state of equilibrium by shifting vehicles. The outer iteration step
checks if new routes with lower impedance can be found as a result of the current network
state (see "Equilibrium assignment" on page 320).
The Equilibrium assignment LUCE uses the LUCE algorithm, which was conceived by
Guido Gentile. He collaborated with PTV to produce a practical implementation of the
method in Visum. Exploiting the inexpensive information provided by the derivatives of the
arc costs with respect to arc flows, LUCE achieves a very high convergence speed, while
it assigns the demand flow of each OD pair on several paths at once (see "Linear User Cost
Equilibrium (LUCE)" on page 331).
The Equilibrium_Lohse assignment models the "learning process" of road-users in the
network. Starting with an "all or nothing assignment", drivers consecutively include
information gained during their last journey for the next route search (see
"Equilibrium_Lohse" on page 346).
The Assignment with ICA brings the impedances at junctions into focus. It explicitly
regards lane allocations and further details. Especially the interdependencies between the
individual turns at a node are considered. With other assignment procedures, the detailed
consideration of node impedances usually leads to an unfavorable convergence behavior.
The assignment with ICA uses turn-specific volume-delay functions which are continuously
re-calibrated by means of the ICA. This leads to a significantly improved convergence
behavior (see "Assignment with ICA" on page 354).
The Stochastic assignment takes into account the fact that skims of individual routes
(journey time, distance, and costs) that are relevant for the route choice are perceived
subjectively by the road users, in some cases on the basis of incomplete information.
Additionally, the choice of route depends on the road user's individual preferences, which
are not shown in the model. In practice, the two effects combined result in routes being
chosen which, by strict application of Wardrop's first principle, would not be loaded,
because they are suboptimal in terms of the objective skims. In the Stochastic assignment,
an alternative quantity of routes is initially calculated, therefore, and the demand is
distributed across the alternatives on the basis of a distribution model (e.g. Logit) (see
"Stochastic assignment" on page 365).
The TRIBUT procedure, which was developed by the French research association
INRETS, is particularly suitable for modeling road tolls. Compared to the conventional
procedures which are based on a constant time value, TRIBUT uses a concurrent
distributed time value. A bicriterial multipath routing is applied for searching routes, which
takes the criteria time and costs into account. Road tolls are modeled as transport systemspecific road toll value, either for each Visum route or for link sequences between userdefined nodes (non-linear toll systems) (see "TRIBUT" on page 376).
In co-operation with the University of Rome, Visum provides the Dynamic User
Equilibrium (DUE). Additionally, the algorithm includes a blocking-back model, can regard
time-varying capacities as well as road tolls and provides a departure time choice model
(see "Dynamic User Equilibrium (DUE)" on page 389).

PTV AG

Chapter 5.2: Example network for the PrT assignment procedures

The Dynamic Stochastic assignment differs from all the previously named procedures as
a result of the explicit modeling of the time axis. The assignment period is divided into
individual time slices, with volume and impedance separated for each such time slice. For
each departure time interval, the demand is distributed across the available connections (=
route + departure time) based on an assignment model as in the case of the stochastic
assignment. With this modeling, temporary overload conditions in the network are
displayed, a varying choice of routes results in the course of the day, and possibly also a
shift of departure time with respect to the desired time (see "Dynamic stochastic
assignment" on page 419).

For each of the mentioned assignment procedures any number of demand matrices can be
selected for assignment.

One demand matrix of one PrT transport system, for example, a car demand matrix is
assigned.
Multiple demand matrices which contain the demand for one or multiple PrT transport
systems, for example, a car demand matrix and a HGV demand matrix are assigned
simultaneously.

Abbreviations which are used together with the User Model PrT, shows the table 47.
v0

Free flow speed [km/h]

t0

Free flow travel time [s]

vCur

Speed in loaded network [km/h]

tCur

Travel time in loaded network [s]

Impedance = f (tCur)

Volume of a network object [car units/time interval] = sum of volumes of all PrT transport systems
including basic volume (preloaded volume)
NumTSys

q =

i = 1

( q i PCU i ) + q preloadedVolume

qmax

Capacity [car units/time interval]

Sat

Volume/capacity ratio

Fij

Number of trips [veh/time interval] for relation from zone i to zone j.

Demand matrix which contains the demand for all OD pairs.

Table 47: Abbreviations used in the User model PrT.

5.2

Example network for the PrT assignment procedures


The way the PrT assignment procedures work is described with the example illustrated in
illustration 57. The example analyzes the relation between traffic zone "village A" and traffic
zone "city X". The following assumptions apply:

PTV AG

Access and egress times are not considered, that is, they are set to 0 minutes.
Turn penalties are not considered.
Capacity and demand refer to one hour.

213

Chapter 5: User model PrT

The traffic demand between A-Village and X-City is 2,000 car trips (car.fma matrix) during
peak hour.
To explain simultaneous assignment of multiple demand matrices 200 additional HGV trips
(hveh.fma matrix) are considered. One HGV corresponds to two car units.
On federal roads (link type 20) there is a speed limit of 80 km/h for HGVs.

The example network contains three routes which connect A-Village and X-City. The routes
run via the following nodes:

Route 1: 10 11 41 40
Route 2: 10 11 20 21 30 31 40
Route 3: 10 12 21 30 31 40

Route 1 mainly uses country roads and is 26 km long. It is the shortest route. Route 2 is 30 km
long. It is the fastest route because the federal road can be traversed at a speed of 100 km/h
if there is free traffic flow.
Route 3 which is also 30 km long is an alternative route which only makes sense if the federal
road is congested.
village A
10

10

12

11

11

41

20

40

21

30

city X

31

Illustration 57: Example network


LinkNo

From Node To Node

Type

Length [m]

Capacity [car units/h]

v0-PrT [km/h]

10

20 Federal road

5,000

1,200

100

11

11

20

20 Federal road

5,000

1,200

100

20

21

20 Federal road

5,000

1,200

100

20

40

90 Rail track

10,000

21

30

20 Federal road

5,000

1,200

100

Table 48: Example network

214

PTV AG

Chapter 5.3: PrT Paths

LinkNo

From Node To Node

Type

Length [m]

Capacity [car units/h]

v0-PrT [km/h]

30

31

20 Federal road

5,000

1,200

100

31

40

20 Federal road

5,000

1,200

100

11

41

30 Country road

16,000

800

80

40

41

30 Country road

5,000

800

80

10

10

12

40 Other roads

10,000

500

60

11

12

21

40 Other roads

5,000

500

60

Table 48: Example network

The example network in table 48 is saved to the folder ...Users\Public\Public documents\PTV


Vision\PTV Visum 13\Example_net.

5.3

Version file: Example.ver


Assignment parameters file: Auto.par

PrT Paths
All assignments in Visum in the PrT as well as in the PuT are route based. This means that
possible paths in the assignment are calculated for each origin-destination relation and loaded
with a demand share. All other results, especially the different network object volumes and the
skim matrices are derived from these loaded paths. Paths are therefore the central result of the
assignment procedure.
The table 49 displays the PrT paths provided by an equilibrium assignment in Example.ver, in
link-based display.
Origin zone
100

100

100

Destination zone Path index


200

200

200

Index

Link

From node

To node

1
1

10

11

11

20

20

21

21

30

30

31

31

40

10

11

11

41

41

40

10

10

12

11

12

21

Table 49: Link-based PrT paths of a PrT assignment

PTV AG

215

Chapter 5: User model PrT

Origin zone

Destination zone Path index

Index
3

Link

From node
5

21

To node
30

30

31

31

40

Table 49: Link-based PrT paths of a PrT assignment

For private transport, you can edit paths manually, because paths are available as network
objects here (see "Paths" on page 52).

5.4

Impedance and VD functions


Subjects

5.4.1

Impedance of a PrT route


Predefined VD functions
Example of the calculation of the link impedance
User-defined VD functions

Impedance of a PrT route


All assignment procedures are based on a short-route algorithm that determines low
impedance routes. The impedance of a PrT route is volume-dependent and consists of the
following impedances:

Impedances of used links (see "Impedances of links" on page 217)


Impedances of used turns, which are also called 'node impedance' (see "Impedances at
node" on page 226)
Impedances of the used connectors (see "Impedances of connectors" on page 217)
Impedances of the used main turns (see "Impedances of main turns" on page 218)

The route choices of travelers depend on objective and subjective factors. The route choice is
particularly determined by the following skims:

The anticipated travel time for the route


Route length
Possible road tolls

In addition to this, a multitude of other factors can influence route choice. One can imagine, for
example, that road users who know their way around will choose other routes than people who
do not know the area and who mainly orient themselves according to the sign-posted traffic
network. Impedance is therefore defined for each transport system and can be customized by
the user. By default, it depends on the following variables:

216

Transport system-specific travel time, in loaded network tCur [s]

Link length [m]


Transport system-specific road tolls [money units]
User-defined AddValues
Link type factor [-]

PTV AG

Chapter 5.4: Impedance and VD functions

You can also define the impedance in detail. You are then provided with all direct and indirect
numerical attributes of the network objects links, turns, connectors and main turns, for the
definition of the impedance of a route (see User Manual, Chpt. 5.2.2, page 992).
When composing the impedance summands, it can be differentiated between two basic
components:

Summands, which apply depending on the traffic volumes (for example value calculated
tCur with a VD function)

Summands, which are not dependent on the network object volume (for example, toll or link
length)

The time tCur of a network object is calculated with capacity restraint functions (VD functions).
Based on the assumption that the travel time (impedance) of network objects increases with
increasing traffic volume, all assignment procedures are in turn based on the assumption that
travel times of network objects are a monotone incremental function of traffic volume. Thus, in
case of increased traffic in the network the effect of deterrence to alternative routes can be
modeled (see "Predefined VD functions" on page 218).
Because the variables have different units (seconds, meters, money units), impedance cannot
be written in a universally applicable unit. For a combination of the variables, travel time, and
road toll, it may be convenient to express impedance in terms of money units. In this case,
travel times are converted into money units using a "value of time" factor.

Impedances of links
For every PrT-transport system of a link, a TSys-specific travel time (t0_TSys) for free flow is
defined which is calculated from:

link length
permitted speed (v0_PrT) of the link used

maximum speed of the transport system (v0_PrTSys)

A capacity-dependent impedance function continuously adapts this basic travel time


depending on the current traffic volume (see "Predefined VD functions" on page 218).

Impedances of turns (Impedances at node)


Visum calculates turn impedances for every turn permitted at a node. A turn impedance
includes an impedance time penalty t0 which increases in dependence on volume and
capacity. Because the turns are positioned at the node, the impedances at turns are often
described as impedances at node (see "Impedances at node" on page 226).

Impedances of connectors
Connector impedances are regarded as follows:

PTV AG

Absolute connectors are regarded as being volume-dependent. This means, that the TSysspecific connector time (t0_TSys) does not represent actual impedance which is volumeindependent.

217

Chapter 5: User model PrT

For connectors defined by percentage, they are regarded as volume-dependent, if the


option Connector weights apply to total trips (MPA off) is active. This means, that with
increasing volume the actual connector time tCur_TSys will exceed the connector time
t0_TSys of each connector (see "Predefined VD functions" on page 218). With a high value
for parameter b in the VD function and usage of the equilibrium assignment, a relatively
exact distribution of traffic onto the connectors can be achieved.

Note: The impedance of turns and connectors in contrast to links only depends on the
variable tCur and possibly on the AddValue. Because the impedance of a connector is not
capacity-dependent, the following applies to the access and egress impedance: tCur = t0. The
proportional distribution of traffic demand onto different connectors is, however, reached
through a virtual capacity, so that tCur > t0 can also apply to connectors. For each assignment,
the particular virtual capacity (100%) is then recalculated from the summed up volume total
and the demand to be assigned in the current assignment, e.g. Vol(car-business) + Vol(carprivate) + Demand(HGV) = 100% Connector capacity.

Impedances of main turns


Just like turn impedances, in Visum main turn impedances are calculated for each main turn
permitted at a main node based on the volume and selectively a VD function, TModel or ICA.

Preloaded volume
When impedances are determined, preloaded volumes can be considered. Preloaded volumes
can be either user-defined additional values or volume values which result from the
assignment of a different matrix.

5.4.2

Predefined VD functions
Travel times for PrT are determined by the saturation of links and turns which result from the
traffic volume and the capacity of these network objects. Due to this, PrT travel times vary in
contrast to PuT journey times, and can only be anticipated to a certain degree before a trip. The
PrT travel time of a route between two zones consists of the following components:

Access and egress times


Travel time on links
Turn time at intersections

For free traffic flow, the travel time t0 of a link can be determined from the link length and the
free-flow speed v0. For turns at an intersection, the turn time t0 is specified directly. In loaded
networks, the link travel time and the turn time is determined by a so-called volume-delay
function (or VD function). This capacity restraint function describes the correlation between the
current traffic volume q and the capacity qMax. The result of the VD function is the travel time in
the loaded network tcur. Visum provides several function types for the volume-delay functions:
1. the BPR function from the Traffic Assignment Manual of the United States Bureau of Public
Roads (illustration 58)
2. a modified BPR function with a different parameter b for the saturated and unsaturated
state (table 52)
3. a modified BPR function, for which an additional supplement d per vehicle can be specified
in the saturated state (table 53)

218

PTV AG

Chapter 5.4: Impedance and VD functions

4. the INRETS function of the French Institut National de Recherche sur les Transports et leur
Scurit (illustration 59)
5. a constant function where the capacity does not influence travel time (tCur = t0)
6. and several functions for turning processes (i.e. t0 is added, not multiplied) as well as
function type linear bottleneck which are used by turn type
7. another modified BPR function (LOHSE) with a linear rise in the oversaturated section, in
accordance with the queuing theories, in order to achieve more realistic times in the
oversaturated section and a better performance in assignments since small changes to the
volume do not result in disproportionate travel time changes. The function is monotonic,
continuous, and differentiable even where sat = satcrit
Note: In addition to the volume-delay functions provided in Visum, you can also specify
user-defined VD functions (see "User-defined VD functions" on page 225).
The table 50 shows the variables used in the descriptions of the VD functions.
sat

q
q max c

Volume/capacity ratio sat = ------------------

satcrit

Degree of saturation at which the linear section of the volume-delay function starts

tcur

Current travel time on a network object in loaded network [s] (tCur)

t0

Travel time on a network object with free flow time [s]

Current volume = sum of volumes of all PrT transport systems including preloaded volume
[car units/time interval]
NumTSys

q =
qmax

i = 1

( q i PCU i ) + q preloadedVolume

Capacity [car units/time interval]

Table 50: Variables used in VD functions

The parameters mentioned in table 51 apply to all VD functions. Function-specific parameters


are listed with the respective VD function.

a, b, c

User-defined parameters
a [0.00;), b {0.00...10.00}, c [0.00;)

Table 51: Parameters for all VD functions

PTV AG

219

Chapter 5: User model PrT

Volume-delay graph for a=1 and c=1, tCur = t0 f(q/qMax)


10

f(q/qMax)

6
b=2
b=3

b=4
b=5

0
0

0,2

0,4

0,6

0,8

1,2

1,4

1,6

q / qMax

Illustration 58: VD function type BPR according to the Traffic Assignment Manual

satcrit

satcrit = 1

a, b, b, c

Parameters a [0.00;), b, b {0.00...10.00}, c [0.00;)

Table 52: VD function type BPR2: modified BPR

, where

satcrit

satcrit = 1

a, b, c, d

a [0.00;), b {0.00 ...10.00}, c [0.00;), d {0.00...100.00}

Table 53: VD function type BPR3: modified BPR

with

a, c

a [1.1;100), c [0.00;100)

Table 54: VD function type CONICAL (Spiess)

220

PTV AG

Chapter 5.4: Impedance and VD functions

with

a, c

, where

a [1.1;100), c [0.00;100)

Table 55: VD function type CONICAL_MARGINAL

A marginal-cost version of the CONICAL function, proposed by Spiess to calculate a system


optimum instead of user optimum in equilibrium assignment.

, where

satcrit

satcrit [0.00;10]

a, b, c, d

a [0,0001;100], b [0,0001;10000], c [0.00;100], d [0,0001;10000]

Table 56: VD function type EXPONENTIAL

The function models queuing at entry legs whose inflow is restricted by ramp metering signals.

, where

satcrit

satcrit = 1

current volume = sum of volumes of all PrT demand segments [car units/time unit] including
basic volume (preloaded volume)
AnzNSeg

q =

i = 1

( q i PkwE i ) + q Vorbelastung

user-defined parameter a {0.00..1.10}

user-defined capacity parameter c [0;)

Table 57: VD function type INRETS

PTV AG

221

Chapter 5: User model PrT

Volume-delay graph for c=1, tCur = t0 f(sat)


10

f(sat)

a = 0,0
a = 0,2

a = 0,4
a = 0,6
a = 0,8

0
0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

1,1

1,2

1,3

1,4

1,5

1,6

sat

Illustration 59: VD function type INRETS

The impedance functions listed in table 58 are particularly suited to the modeling of turn
impedances. A capacity-dependent wait time is thus added to each basic wait time t0.
LOGISTIC

QUADRATIC
SIGMOIDAL_MMF_NODES (formerly SIGMOIDAL_MMF)

SIGMOIDAL_MMF_LINKS (formerly SIGMOIDAL_MMF2)


Unlike SIGMOIDAL_MMF_NODES, the wait time term is not added
to t0 but multiplied by it.

a, b, c, d

Table

222

a, b, c, d [0.00100.00}, f {0.00...10.00}.
The value of parameter f of VD function types SIGMOIDAL_MMF_NODES and
SIGMOIDAL_MMF_LINKS ranges from 0..100.
58:
VD
function
types
SIGMOIDAL_MMF_LINKS

LOGISTIC,

QUADRATIC,

SIGMOIDAL_MMF_NODES,

PTV AG

Chapter 5.4: Impedance and VD functions

AKCELIK

The function describes delays at nodes with


a = duration in hours
b = family parameter
d = capacity of lane per hour
Table 59: VD function type AKCELIK
AKCELIK2

a = duration in hours
b = family parameter
d = 1 / Number of lanes (of the link)
qmax = capacity of the network object (of the link)
Unlike AKCELIK, the denominator of this function references directly to the capacity of the network
object. Besides, AKCELIK2 is no wait time function at a node but models the speed reduction on a link.
Value d is intentionally a free parameter, although alternatively the link attribute 'Number of lanes' could
be evaluated directly. By removing this attribute which should always carry the physically existing number
of lanes (for example for the Vissim export), a suitable value of d for example, can model the frictional
loss by pulling in and out events for parking. d = 0.6 would therefore correspond to a slightly lower
capacity than two lanes.
Table 60: VD function type AKCELIK2

satcrit

satcrit [0.00;10]

[(a + 1) t0] represents tCur with sat = 1

a [0.00;1000]
b

Determines the value of the increasing rise up to sat = satcrit

b [0.00;10]
c

Scaling parameter for the determination of the dimensions of q and qmax

c [0.00;100]
Table 61: VD function type LOHSE

PTV AG

223

Chapter 5: User model PrT

LOHSE
45,0
40,0
35,0
30,0
tcur

b=2
25,0

b=3
b=4
b=5

20,0
15,0
10,0
5,0

2,50

2,40

2,30

2,20

2,10

2,00

1,90

1,80

1,70

1,60

1,50

1,40

1,30

1,20

1,10

1,00

0,90

0,80

0,70

0,60

0,50

0,40

0,30

0,20

0,10

0,00

0,0

sat

Illustration 60: VD function type LOHSE


Linear bottleneck

This function type stems from Metropolis and should not be used in static assignments, as it rises
strongly when reaching the saturation while the previously augmenting VolCapRatio is unaccounted for.
Table 62: VD function type Linear Bottleneck

Some projects may require non-standard VD functions, e.g. because they include further link
attributes or because the conversion of volumes to passenger car units (PCUs) is projectspecific. In this case, you can add your own functions to the pre-defined volume-delay
functions (see "User-defined VD functions" on page 225).

5.4.3

Example of the calculation of the link impedance


The table 63 to table 66 show an example in which link impedance consists of the current
travel time and road toll. For HGV transport systems which have a higher "value of time" the
influence of road tolls on link impedance is less than for car transport systems.
Link length

10,000 m

Permitted maximum speed v0 car

130 km/h

Permitted maximum speed v0 HGV

100 km/h

Road toll for cars

Road toll for HGV

Capacity

3,000 car units/h

Table 63: Input data of the calculation of the link impedance

224

PTV AG

Chapter 5.4: Impedance and VD functions

Car volume

1,000 cars/h = 1,00 car units/h

HGV volume

100 HGV/h = 200 car units/h

Value of time VOTcar

18 /h = 0.005 /s

Value of time VOTHGV

36 /h = 0.010 /s

VD function according to BPR

with a = 1, b = 2, c = 1

Table 63: Input data of the calculation of the link impedance

Car travel time in unloaded network

t0 car = 10,000 3.6 / 130 = 277s

Car travel time in loaded network

tCur car = 277 (1+(1,200/3,000)) = 321s

Car speed in loaded network

vCur car = 10,000 3.6 / 321 = 112 km/h

Table 64: Car travel times and speeds


HGV travel time in unloaded network

t0 HGV = 10,000 3.6 / 100 = 360s

HGV travel time in loaded network

tCur HGV = MAX (321s; 360s) = 360s

HGV speed in loaded network

vCur HGV = 100 km/h

HGV speed only declines if the volume is more than 1644 car units/h, if
tCur = 277 (1+(1644/3000)) = 360s
Table 65: HGV travel times and speeds
Car impedance in loaded network

RCar = 1 + 0.005 321 = 2.61

HGV impedance in loaded network

RHGV = 5 + 0.010 360 = 8.60

Table 66: Calculation of link impedance for HGV and car

5.4.4

User-defined VD functions
You can set up user-defined VD functions for the following use cases:

To include further attributes for links, turns and connectors in the calculation
To calculate PCUs in a non-standard way
To define separate volume-delay functions for different transport systems

Volume-delay functions are very often evaluated within the assignment methods, so
computational efficiency is a key consideration. Therefore Visum adopts a compiled rather
than an interpreted approach to user-defined volume-delay functions. Users program their
functional forms as a dynamic-link library (DLL) following a given template. All such *.dll files
need to be copied into the following project directory, which is created during the installation
and which is scanned by Visum at start-up: %APPDATA%\PTV Vision\PTV Visum
13\UserVDF-DLLs (see User Manual, Chpt. 5.2.1.6, page 984).
Note: A *.bmp file with identical file name which is stored in the same folder will be displayed
for VDF selection.

PTV AG

225

Chapter 5: User model PrT

5.5

Impedances at node
Intersections are modeled as nodes or as main nodes in Visum. Intersections of roads and/or
railway tracks are bottlenecks in an urban transport network. At the intersections, conflict
points have to be passed in succession by the non-compatible traffic flows. The order in which
the flows traverse the conflicting areas depends on the type of control:
To choose the route within an assignment procedure, the impedance on alternative routes is
decisive, which results in the sum of impedances of all traversed network objects. The
bottleneck effect of a node is thus displayed for all variants of the traffic control by the
impedance of the turn used. The impedance of turns usually corresponds exactly to the travel
time tCur, thus the time required to traverse the node in the turning direction of the route.
For calculating tCur per turn Visum offers three different models that represent the different
compromises between data entry and computing time on the one hand and accuracy and reallife situations on the other.

Turns VDF (see "Impedance of turns from Turns VD function" on page 228)
Nodes VDF (see "Impedance of turns from Nodes VD function" on page 228)
Intersection Capacity Analysis ICA (see "Intersection Capacity Analysis according to the
Highway Capacity Manual (ICA)" on page 229)
To use ICA during assignment, select the method Node impedance calculation (ICA).
Alternatively you can based on an assignment result select method From previous
assignment with ICA.

Comparing advantages and disadvantages in table 67 is to help you choose the appropriate
calculation model for your project.
Model

Advantage

Disadvantage

Turns VDF (see


Little input complexity (per turn
"Impedance of turns
merely capacity and t0)
from Turns VD
Calculation fast
function" on page 228) Assignment fast convergence

Time required for the turning


movement only takes the turning
volume into account, not the amount
of possible conflicting volumes
(separable cost functions)

Nodes VDF (see


Input complexity only slightly larger
"Impedance of turns
than for turn VD functions
from Nodes VD
(additionally capacity and t0 for the
function" on page 228)
node itself as well as designating
subordinated links)
Calculation fast
For subordinate turns at two-way
stop nodes, the time required due to
its own volume increases by an
additional penalty, which depends
on the total volume/capacity ratio of
the node and therefore on the
volumes of conflict flows.

Assignment convergence slower due


to the inseparable penalty
Compared to ICA, taking conflicting
volumes into account is extremely
simpler due to the fixed penalty

Table 67: Advantages and disadvantages of the node impedance model

226

PTV AG

Chapter 5.5: Impedances at node

Model

Advantage

Disadvantage

Node impedance
Impedance calculation precisely
Input complexity considerably higher:
calculation (ICA) (see
considers lane allocation and signal
Instead of capacity and t0, model the
"Intersection Capacity
control. Special turn pockets for
lane allocation at the node and Analysis according to
example, are capacity-increasing
where available - the signal control in
the Highway Capacity
and dependent on the entered signal
detail
Manual (ICA)" on
timing, protected and permitted turns Calculation more time consuming
page 229)
are calculated correctly
Assignment convergence slow due to
the inseparable impedance model,
sometimes without additional
measures not at all
From previous
assignment with ICA
(see "Assignment with
ICA" on page 354)

In the Assignment with ICA,


Increased efforts required for the
convergence is reached by regular
comprehensive modeling of
adjustment of the Turns VDFs to the
geometry and control at the nodes to
wait times and capacities calculated
be regarded.
by ICA.
Comparably computation timeconsuming.
The HCM 2000 method used for ICA
regards the lane allocation and
conflicting turn flows in detail.

Table 67: Advantages and disadvantages of the node impedance model

Due to the reasons mentioned we recommend the following for the selection.

For comprehensive models, modeling with VD functions for turns or nodes is appropriate.
ICA cannot be recommended here, because the input complexity for the detailed supply of
nodes with geometry and control data is usually too high. Furthermore, the result after each
acceptable computing time due to the slow convergence of the assignment still contains
approximation errors, which are around the same size as the accuracy gained through ICA.
ICA however, is the method of choice if you want to subsequently calculate and analyze the
performance of one or more nodes of an existing assignment result. This is how you can
determine which aspects of the node contribute to a high impedance. It is therefore
sufficient to only model those nodes completely which have to be analyzed.
With a classical assignment method (Equilibrium or Equilibrium_Lohse, for example), ICA
is only conditionally recommended due to the known convergence difficulties, and it should
only be applied to small-scale analyses with some 100 nodes. To avoid these problems, the
Assignment with ICA method is recommended.
With an equilibrium assignment, best results can be achieved with either the
Equilibrium_Lohse method (see "Equilibrium_Lohse" on page 346) or the From
previous assignment with ICA method (see "Assignment with ICA" on page 354), since
these are more robust towards impedance variations.

In most cases you will globally decide on a calculation model. You can however also combine
different calculation methods within a network, (for example, Turns VD functions as standard
model and ICA simply for very important nodes with complex lane allocation or large conflicting
flows).
All calculation models are based on turn volumes in car units per hour, which are determined
through the user's settings, either from the assigned volume or from counted data via a factor.

PTV AG

227

Chapter 5: User model PrT

5.5.1

Impedance of turns from Turns VD function


In the simplest calculation model tCur, the time requirement of a turning vehicle is calculated
from the turning time t0 in the unloaded network and the saturation of turns using a VD function.
You can use one of the pre-defined functional forms (see "Predefined VD functions" on
page 218) as VD functions or select a user-defined functional form (see "User-defined VD
functions" on page 225). Typical Turn VD functions make up the sum (not the product) of t0 and
a saturation-dependent term. Examples are the VD functions Akcelik, Exponential, Constant,
Logistic, Quadratic and TMODEL_Nodes.
The attributes mentioned in table 68 are considered for the calculation.
Network object

Attribute

Turn

Capacity PrT The capacity of the turn in PCUs/hour

Description / Effect

Turn

t0 PrT

The time required for a turning movement in unloaded state

Turn

Type

Usually specifies the direction of the turn

Table 68: Attributes for the impedance calculation from Turns VD function

5.5.2

Impedance of turns from Nodes VD function


In this model, turn delays are calculated in two steps. First, a node delay is calculated by
applying a VD function to the vol/cap ratio of the node. Each turn penalty is the sum of node
delay and the turn-specific time (calculated with VD function set for turns). Node delay only has
an affect on turns from a non-prioritized approach. This approach links have to be marked with
the attribute TModelSpecial (see User Manual, Chpt. 2.40, page 578).
The attributes mentioned in table 69 are considered for the calculation.
Network object Attribute

Description / Effect

Turn

Capacity PrT The capacity of the turn in PCUs/hour

Turn

t0 PrT

The time required for a turning movement in unloaded state

Turn

Type

Usually specifies the turning direction

Node

Capacity PrT The total capacity of the node in PCUs/hour

Node

t0 PrT

The additional time required for a non-prioritized turning movement (all


the same) in unloaded state

Table 69: Attributes for the impedance calculation from Node VD function

Turn time penalties are calculated according to the following formulas:


vol(n) = vol(t)
delay(n) = VDF (cap(n), vol(n))
delay(t) = VDF (cap(t), vol(t))

IF n has no link with TModelSpecial = 1, THEN


tCur(t) = delay(t) + delay(n) for all turns t via node n

228

PTV AG

Chapter 5.5: Impedances at node

IF n has at least one link with TModelSpecial = 1, THEN


tCur(a) = delay(t) for all turns t with a 'from link' to which TModelSpecial = 0 applies
tCur(a) = delay(t) + delay(n) for all turns t with a 'from link' to which TModelSpecial = 1 applies

5.5.3

Intersection Capacity Analysis according to the Highway Capacity


Manual (ICA)
VD functions are usually used to model volume-dependent travel times on links (see
"Impedance and VD functions" on page 216). They can also be used to model volumedependent wait times for turns or complete nodes (see "Impedance of turns from Turns VD
function" on page 228 and "Impedance of turns from Nodes VD function" on page 228).
By contrast the Highway Capacity Manual (HCM) published by the US Transportation
Research Board contains internationally recognized guidelines on calculating the level of
service and other performance indicators for intersections, based on the detailed junction
geometry and various control strategies. Visum computes performance indicators such as
capacity, delays or LOS either according to the guidelines defined in the operation model HCM
2000 or according to HCM 2010 guidelines.
Note: In the following the implementation of the HCM 2000 in Visum is described. For most
of the control types (except for signalized nodes), the HCM 2010 differs from the HCM 2000
in only a few aspects. The deviating portions are highlighted in the text. Since the HCM is
provided in English only, certain English expressions and descriptions have not been
translated for a better traceability in the original document.
For intersection points of the same level, the calculation differentiates between the following
control types (attribute Effective control type at node):

Uncontrolled nodes (see "Uncontrolled nodes" on page 230)


Signalized intersections (see "Signalized nodes" on page 230)
Static priority rules using the traffic signs StVO 306 or 301 (German road traffic regulations)
for the main road and StVO 205 or 206 for the subordinate road (see "Two-way stop nodes"
on page 250)
All-Way stops (only for North America) (see "All-way stop" on page 260)
Roundabouts
Visum offers two different models for the analysis of roundabouts:

The method developed by R. M. Kimber, (Kimber 1980), (Kimber, Hollis 1979), (Kimber,
Daly 1986), which is also described in the British guideline TD 16/93 "The Geometric
Design of Roundabouts", is based on the empirical study of numerous roundabouts and
the statistical adjustment of a model which estimates capacities in dependency of the
geometry (see "Roundabouts according to the TRL/Kimber 2010 method" on
page 272).
The method described in the Highway Capacity Manual 2010, chapter 21 (see
"Roundabouts according to the HCM 2010 method" on page 267).

The method according to TRL/Kimber has the advantage of taking comprehensive


empirical results on the influence of geometry on the permeability of a roundabout into
consideration and has been successfully implemented for nearly three decades.

PTV AG

229

Chapter 5: User model PrT

The method according to HCM is recommended, if in theory you prefer consistency for all
control types (roundabouts also according to HCM like signalized and two-way stop nodes)
within a project. Furthermore, the method is not dependent on observations which were
only obtained through driving behavior studies in Great Britain.
For the calculation, the effective control type is decisive instead of the control type. These
values differ in the following: Signalized nodes are regarded as yield-controlled nodes, if no SC
has been allocated to them or if the SC has been turned off (Signal control attribute Turned
off).
Notes: Throughout the model description, special provision for right or left turns relates to
right-hand traffic. For Visum models with left-hand traffic the roles of right and left turns are
reversed (see User Manual, Chpt. 1.5, page 65).
U-turns are never considered in HCM 2000. In Visum it is possible to treat U-turns as far left
turns through the corresponding setting in the procedure parameters for intersection
impedance analysis (in left-hand traffic accordingly as far right turns). This calculation is then
no longer HCM conform. HCM 2010 regards U-turns at two-way stop nodes. Here, the
processing is performed according to HCM 2010 in Visum. Other control types are processed
according to HCM 2000.

5.5.3.1

Uncontrolled nodes

For uncontrolled nodes the impedance of a turn is calculated using a VD function from the node
volume (= Sum of turn volumes) and the node capacity, therefore exactly like calculating the
model Nodes VD function (see "Impedance of turns from Nodes VD function" on page 228),
however without a term for each turn.
The Visum attributes listed in table 70 are considered for the calculation.
Network object Attribute

Description / Effect

Node

Capacity PrT The total capacity of the node in PCUs/hour

Node

t0 PrT

The time required in a turning movement (all equal) in unloaded state

Table 70: Attributes for the calculation regarding uncontrolled nodes

5.5.3.2

Signalized nodes

Notes: In the HCM 2000, chapter 16 describes signalized nodes. In HCM 2010, find the
descriptions in the chapters 18 and 31.
Instead of the method described here for signalized nodes, the method for yield-controlled
nodes is applied to nodes and main nodes of the signalized control type, to which no SC has
been allocated or whose SC has been turned off.
The basic flow chart for performing capacity analyses for signalized intersections is displayed
in illustration 61. You input the intersection geometry, volumes (counts or adjusted demand
model volumes), and signal timing. The intersection geometry is deconstructed into lane (or
signal) groups, which are the basic unit of analysis in the HCM method.

230

PTV AG

Chapter 5.5: Impedances at node

A lane (or signal) group is a group of one or more lanes on an intersection approach having the
same green stage. For example, if an approach has just one pocketed exclusive left turn and
one shared through and right turn, then there are usually two lane groups the left and the
shared through/right.
Note: According to HCM 2010, the lane allocation follows different rules. Here, shared lanes
always form a separate lane group. For more details, please refer to HCM 2010, page 18-33.
The volumes are then adjusted via peak hour factors, etc. For each lane group, the saturation
flow rate (SFR), or capacity, is calculated based on the number of lanes and various
adjustment factors such as lane widths, signal timing, and pedestrian volumes. Having
calculated the demand and the capacity for each lane group, various performance measures
can be calculated. These include, for example, the v/c ratio, the average amount of control
delay by vehicle, the Level of Service, and the queues.

I n p u ts
Ge om etry
V olum es
S ig nal tim in g

L a n e G ro u p s &
D em an d A d j
L an e Gro uping s
P ea k h our fa ct or

S atu ratio n F lo w R a te
(C ap a city)
Ba sic s
A djus tm en t F a ct ors

C ap ac ity A n alysi s
V /C R a tio
A v erage D elay
L ev el o f S ervic e
Qu eue s

Illustration 61: Capacity analysis process for signalized nodes

Note: For HCM 2010, the corresponding flow diagram can be found in HCM 2010, page 1832.
If you use the HCM 2000 or HCM 2010 operations model for signalized nodes, the Visum
attributes in table 71 will have an effect. Make sure that they are set to realistic values prior to
running the analysis.
Alternatively to the calculation method according to HCM, you can apply one of the following
methods:

PTV AG

ICU1
ICU2

231

Chapter 5: User model PrT

Circular 212 Planning


Circular 212 Operations

From the HCM, these procedure differ in just three issues:

Definition of the ideal saturation flow rate


Calculation of the final saturation v/s (volume/saturation flow rate) for the node
Determination of the Level of Service (LOS)

The steps 6, 9 and 13 below describe the calculation variants in detail.


Note: Visum allows for control access to RBC and Vissig controllers. Vissig controllers
provide fixed-time control strategies. RBC controllers provide pre-timed or actuated control
strategies (also fully or semi-actuated). HCM 2010 provides a computation method for fixedtime strategies and for traffic-actuated strategies as well. Visum uses fixed-time strategies for
Vissig controllers. The strategy used for RBC controllers depends on the type of traffic
actuation. For a description of this method, please refer to HCM 2010, chapters 18 and 31.
Prior to the computation, Visum imports the signal control data for the control strategy from
the corresponding control file.
Network object

Attribute

Description / Effect

Link

ICAArrivalType

Level of platooning in traffic arriving at the ToNode,


subsequently used in the steps 10 + 14a

Link

ICAUpstreamAdj

Adjustment factor for upstream filtering / metering, used in


the steps 10b + 14b

Link

ShareHGV

Proportion of heavy goods vehicles, used in step 6b. One


value applies to all turns originating from the link

Link

Space per PCU

Used in step 6 for the calculation of the number of vehicles


that fit on a pocket lane

Link

Slope

Used in step 6

Node

ICAPHFVolAdj

Factor for adjustment of initial volumes to peak volumes.


Volumes are divided by both node and turn adjustment
factors.

Node

ICALossTime

Used in step 9. Only required for SG-based signal control.


For other types of signal control the value is inferred
automatically.

Node

ICAUsePresetLossTime Decides whether the node attribute ICALossTime is to be


used or an automatically calculated value for the loss time
computation in step 9.

Node

ICAIsCBD

Is the node located in the Central Business District?; used in


step 6e

Node

ICASneakers

Number of vehicles which can line up in the node area


during a cycle. The value in [veh] applies to all movements
at the node The cycle time is used for the minimum capacity
calculation for each movement.

Node

SC number

Points to the signal control

Table 71: Input attributes for signalized nodes

232

PTV AG

Chapter 5.5: Impedances at node

Network object

Attribute

Description / Effect

Geometry

All

Geometry data of lanes, lane turns and crosswalks

Turn

ICAPHFVolAdj

Initial volume adjustment to peak period; volumes are


divided by both node and turn adjustment factors

Turn

ICA Preset saturation


flow rate

Overwrites optionally the global saturation flow rate in the


procedure parameters. Can be overwritten by the specific
lane value of this attribute, if applicable.

Signal Control

All

Definition of signal groups, stages (where applicable), and


signal timing

SC

Used intergreen method Is used in step 9 for loss time calculations

SC

Turned off

If an SC is marked as 'turned off', the node will be calculated


according to the yield control control type.

Signal group

ICA loss time


adjustment

Is added to the actual green time. The actual green time and
ICA loss time adjustment sum up to the green time on which
all computations are based.

Leg

ICA bus blockage

Adjustment factor for the saturation flow rate for


consideration of bus stops.

Leg

ICA parking

Adjustment factor for the saturation flow rate for


consideration of parking events.

Leg

Bicycle volume

Number of bicyclists per hour for the determination of the


adjustment factor for the saturation flow rate.

Lane

Number of vehicles

User-defined number of vehicles 0.0 the pocket


accommodates. This attribute is only regarded if the attribute
Use number of vehicles is true and if the global procedure
parameter 'Regard pocket length for saturation flow rate
calculation' is active.

Lane

Use number of vehicles

Decision, whether Number of vehicles of the lane shall be


used. If this attribute is not true, the number of vehicles is
determined from the pocket length and the attribute Space
per PCU.

Lane

Length

Lane length if pockets are concerned. This attribute is only


regarded if the attribute Use number of vehicles is not true
and if the global procedure parameter 'Regard pocket length
for saturation flow rate calculation' is active. The number of
vehicles is calculated from the length of the pocket and the
attribute Space per PCU.

Lane

Width

Width of the lane. On this basis, the saturation flow rate is


calculated for the lane group to which the lane belongs. The
calculated lane group width is the mean value derived from
the width values of all lanes of this group.

Table 71: Input attributes for signalized nodes

PTV AG

233

Chapter 5: User model PrT

Network object

Attribute

Description / Effect

Lane

ICA Preset saturation


flow rate

Saturation flow rate for the lane after consideration of all


adjustment factors. Use this attribute to set the saturation
flow rate directly, if the HCM-based adjustment factors do
not reflect the actual circumstances of the lane. This value
overwrites the procedure parameter value and also turnrelated values, if applicable.

Lane

ICA Use preset


saturation flow rate

Decision, whether the internally calculated saturation flow


rate shall be replaced by the ICA Preset saturation flow
rate value.

Lane

ICA user-defined
utilization share

Utilization share of the lane within a multi-lane group. The


sum of the input shares is automatically scaled to 100%,
thus you can enter relative weights per lane. This value is
used in step 6.

Lane

ICA use user-defined


utilization share

Decision, whether the internally calculated utilization share


shall be replaced by the ICA user-defined utilization share
value.

Crosswalk

Pedestrian volume

Number of pedestrians per hour for the determination of the


adjustment factor for the saturation flow rate.

Table 71: Input attributes for signalized nodes

Notes: The link attribute Turn on red is not regarded for calculation.
Output is possible through the attributes listed in table 72.
Network object Attribute

Description / Effect

Node

Turn tCur maximum


Turn tCur mean
Turn tCur total

Sum, average, max of turn tCur. Now obsolete, since


available as indirect attributes, but retained for
backward compatibility.

Node

Design volume capacity ratio


PrT

The volume/capacity ratio based on the design


volume

Node

Design volume PrT [veh]

The volume in [veh/h] passed into the HCM


calculation, as defined in the procedure parameters

Node

Design volume PrT [PCU]

The volume in [PCU/h] passed into the HCM


calculation, as defined in the procedure parameters

Node

Level of service

Node

Level of service mean delay

Turn

Design volume PrT [veh] ...

The volume in [veh/h] passed into the HCM


calculation, as defined in the procedure parameters

Turn

Design volume PrT [PCU]...

The volume in [PCU/h] passed into the HCM


calculation, as defined in the procedure parameters

Turn

ICA final volume

After all adjustments

Turn

ICA final capacity

Effective capacity, taking into account all opposing


flows etc.

Table 72: Output attributes for signalized nodes

234

PTV AG

Chapter 5.5: Impedances at node

Network object Attribute

Description / Effect

Turn

ICA final saturation flow rate

After all adjustments

Turn

ICA average back of queue

Average queue length

Turn

ICA back of queue for defined


percentile

Percentile of queue length. Specify in the procedure


parameters which percentile is calculated.

Turn

Level of service

Level of service of the turn

Turn

tCur-PrTSys

TSys-specific travel time tCur in loaded network

Table 72: Output attributes for signalized nodes

Step 1: Lane volume calculation from the movement volumes


This step distributes the movement volumes to lanes according to the user-defined geometry.
The basic distribution rule is to distribute the volumes uniformly to the lanes while taking the
input movement volumes into account. The implemented method is the same as in the All-Way
stop method (see "All-way stop" on page 260). You can overwrite a lane's utilization share
within its lane group, if applicable (lane attribute ICA user-defined utilization share).
Here, HCM 2010 and HCM 2000 differ significantly. According to HCM 2010, the calculation is
much more complex. In HCM 2010, lane volume calculation is an iterative process taking the
saturation flow rates into account. For a description, please refer to HCM 2010, pages 31-30 to
31-37.

Step 2: Volume adjustments by means of peak hour factors


The input lane volumes are adjusted to represent the peak hour volumes through the peak
hour factor (phf). The phf is defined as:
vi = vg / PHF

where
vi

adjusted volume for lane group i

vg

unadjusted (input) volume for lane group g

PHF

peak hour factor (0 to 1.0)

Step 3: Calculation of de facto lane groups left/though/right


De facto lane groups are shared lanes with 100% of their volume making one movement. For
example, if a lane group is a shared left and through lane, and 100% of the lane volume is
making a left movement, then the lane group is converted to a de facto exclusive left lane
group.
In the HCM 2010, the set of lane groups is not affected by the volumes of turning movements.
As described above, shared lanes always form a lane group of its own, even if only a single
turning direction is used actually.

Step 4: Calculation of the types of left turns


The type of left turn needs to be determined in order to calculate the left turn adjustment factor.
The left turn type is set as follows:
1. Fully controlled if all turns of an approach are conflict free during their green times.
2. Fully secured if the left turns are conflict free during green time.

PTV AG

235

Chapter 5: User model PrT

3. Fully secured + permitted if during green time left turns are first fully secured and then
permitted.
4. Permitted + fully secured if during green time left turns are first permitted and then fully
secured.
5. Without left turn stage, all other cases.

Step 5: Proportions of left turning and right turning vehicles calculation by lane
group
The proportion of right and left turn volume by lane group needs to be calculated.
PLT = vLT / vi
PRT = vRT / vi

where
PLT

proportion left turn volume by lane group

PRT

proportion right turn volume by lane group

vi

adjusted volume by lane group

vLT

volume of left turning vehicles by lane group

vRT

volume of right turning vehicles by lane group

In HCM 2010, the iterative method mentioned in step 1 is used for the calculation of the turning
movement proportions on shared lanes. For the description in detail, please refer to HCM
2010, page 31-30 et seqq.

Step 6: Saturation flow rate calculation by lane group


The saturation flow rate is the amount of traffic that can make the movement under the
prevailing geometric and signal timing conditions. The saturation flow rate starts with an
optimum capacity, which is usually is 1,900 vehicles per hour, per lane (vphpl), according to
HCM 2000 and HCM 2010.
For calculation variants ICU1 and ICU2, however, the ideal saturation flow rate is 1,600
vehicles per hour, per lane. For the Circular 212 variant, it is taken from the table below:
Method

2 stages

3 stages

4+ stages

Planning

1,500

1,425

1,375

Operations

1,800

1,720

1,650

This number decreases due to various factors. The SFR is defined as:
si = (so)(N) (fw)(fHV)(fg)(fp)(fa)(fbb)(fLu)(fRT)(fLT)(fLpb)(fRpb)

where

236

si

saturation flow rate of lane group i

so

ideal saturation flow rate per lane (generally 1,900 vphpl)

N
fw

Number of lanes in lane group

fHV

HGV adjustment factor

factor for lane width adjustment

PTV AG

Chapter 5.5: Impedances at node

fg

adjustment factor for approach grade

fp

adjustment factor for parking

fa

adjustment factor for the position of the link to city center (CBD true/false)

fbb

adjustment factor for bus stop blocking

fLu

adjustment factor for lane usage

fRT

adjustment factor for right turns

fLT

adjustment factor for left turns

fLpb

adjustment factor for pedestrians and bicyclists on left turns

fRpb

adjustment factor for pedestrians and bicyclists on right turns

First the description of the main calculation is described and then the various SFR adjustment
factors are calculated.
If an ICAIdealSatFlowRate is specified for a turn, it will replace the final result of step 5. All
adjustment calculations are then bypassed.
The calculations according to HCM 2000 or HCM 2010 are similar. The set of factors taking
effect on the saturation flow rate is the same. Merely the calculations of the factors fw (HCM
2010, page 18-36), fLpb and fRpb differ. The latter are calculated by means of the iterative
method, which is described in HCM 2010, pages 31-30 to 31-37.
Deviating from HCM, the optimal saturation flow rate so of pocket lanes can also be calculated
by the number of vehicles which can be accommodated there. The number n of vehicles can
be set by lane. Alternatively, it results from the division of the pocket lane length by the
standard vehicle length which is set by link.
The alternative calculation method using lane length data is only applied, if the lane group
consists of one or more straight through lane(s) and exactly one pocket lane. The pocket lane
must be of a straight through lane or a through-left type or a through-right type lane. If these
conditions are not satisfied, the regular HCM calculation method will be applied.
The optimal saturation flow rate so of a two-lane group, which consists of a through lane and a
pocket, where there is space for n vehicles, then is as follows:
n 3600
s f = s o + min s o, --------------------
gi

Here, so is the ideal saturation flow rate, n is the number of vehicles which can be
accommodated on the pocket, gi is the effective green time and sf is the resulting saturation
flow rate of the lane group.
For shared lanes, the calculation is more complex. Taking a through lane with only straight
turns and a shared left/straight pocket, then the resulting saturation flow rate sf is as follows:
s ST s LT
s f = --------------------------------------------------------------------------v LT
v ST
- s LT
-------------------- s ST + ---------------------v LT v ST
v LT + v ST

PTV AG

237

Chapter 5: User model PrT

Here, vLT and vST are the volumes of the left and the straight turns, sLT is the ideal saturation
flow rate of the left turn - therefore 1,900 vphpl - and sST is the ideal saturation flow rate of the
through lanes which results from the first equation.

Step 7: Calculation of actual green times


The effective green time (or actual green time for a lane group) needs to be calculated next.
The effective green time results as follows:
gi = Gi + li

where
gi

effective green time per lane group

Gi

green time per lane group

li

loss time adjustment per signal group

Step 8: Capacity calculation per lane group


Related to the SFR is the capacity. The saturation flow rate is the capacity if the movement has
100 % of the green time (this means, the signal is always green for the movement). The
capacity, however, accounts for the fact that the movement must share the signal with the
other movements at the intersection, and therefore scales the SFR by the percent of green
time in the cycle. The capacity of a lane group is then defined as follows:
ci = si (gi / C)

where
ci

capacity i

si

saturation flow rate i

C
gi / C

cycle time
green ratio i

Step 9: Calculation of the critical vol/cap ratio for the entire intersection
The critical v/c ratio of nodes is defined below. The HCM method is concerned with the critical
lane group for each signal stage. The critical lane group is the lane group with the largest
volume/capacity ratio unless there are overlapping stages. If there are overlapping stages,
then the maximum of the different combinations of the stages is taken as the max. For the
description of this method, please refer to HCM 2000, page 16-14, or HCM 2010, page 18-41.
Only if the intergreen method Amber and allred is used for the signal control, loss times will be
determined at all. Per signal group, the loss time results from the amber time and allred time
total minus loss time adjustment.
Xc =

i -s- ci + C-----------L

where
Xc

238

critical saturation (v/c ratio) per intersection

PTV AG

Chapter 5.5: Impedances at node

v--
s ci

volume/capacity ratios for all critical lane groups

C
L

cycle time
loss time total of the signal groups of all critical lane groups

Below is an example calculation of critical lane group per signal stage with overlap.
For computation variant ICU1, Xc is defined as follows:
Xc =

i -s- ci + ---Cv

For computation variant ICU2, Xc is defined as follows:

Xc =

i -s- ci
v

1 1 + -----------------C
----
L 1

Step 10: Mean total delay per lane group


In addition to calculating the critical v/c per intersection, the mean delay per vehicle is
calculated by the HCM method. The mean total delay is defined below.
di = dUiPF + dIi + dRi

where
di

mean delay per vehicle for lane group

dUi

uniform delay

dIi

incremental delay (stochastic)

dRi

delay residual demand

PF

permanent adjustment factor for coordination quality (see "Signal coordination (Signal offset
optimization)" on page 281)

In HCM 2010, the equation looks likewise. However, factor PF has been implemented in factor
dUi. For the description of the calculation procedure, please refer to HCM 2010, page 18-45.
1 R g----i f
P C
PA

PF = ------------------------------------------gi
1 ---C

where

PTV AG

fPA

lookup value (HCM attachment 16 12) based on arrival type

RP

lookup value (HCM attachment 16 12) based on arrival type

239

Chapter 5: User model PrT

Step 10a: Calculation of the uniform delay for each lane group
The uniform delay is the delay expected given a uniform distribution for arrivals and no
saturation. It is calculated as follows:

d Ui

2
1 g----i

C
= 0.5 C ------------------------------------------------------g
i
1 ---- ( min ( X i, 1 ) )
C

where
dUi

uniform delay for lane group i

gi

effective (actual) green time

Xi = v/c

volume/capacity ratio

Step 10b: Calculation of the incremental delay for each lane group
The incremental delay is the random delay that occurs since arrivals are not uniform and some
cycles will overflow. It is calculated as follows:
2 8 ki Ii Xi
d Ii = 900 T ( X i 1 ) + ( X i 1 ) + ----------------------------ci T

where
dIi

incremental (random) delay for lane group i

ci

capacity for lane group i

Xi = v/c

volume/capacity ratio

T
ki

duration of analysis period (hr) (default 0.25 for 15 min)

Ii

upstream filtering / metering adjustment factor (set to 1 for isolated intersection)

lookup value (HCM attachment 16 13) based on the controller type

Step 10c: Delay calculation for the residual demand per lane group
The residual demand delay is the result of unmet demand at the start of the analysis period. It
is only calculated if an initial unmet demand at the start of the analysis period is input (Q). It is
set to 0 in the current implementation. It is calculated as follows:
1800 Q bi ( 1 + u i ) t i
d Ri = -------------------------------------------------------ci T
where

240

dRi

residual demand delay for lane group i

Qbi

initial unmet demand at the start of period T in vehicles for lane group (default 0)

ci

Capacity

T
ui

duration of analysis time slot (hr) (default 0.25 for 15 min)


delay parameter for lane group (default 0)

PTV AG

Chapter 5.5: Impedances at node

ti

duration of unmet demand in T for lane group (default 0)

Step 11: Delay calculation for the approach


The total delay per vehicle for each lane group can be aggregated to the approach and to the
entire intersection with the following equations. The approach delay is calculated as the
weighted delay for each lane group.

di Vi
d A = -------------------- Vi
where
dA

mean delay per vehicle for approach A

di

delay for lane group i

Vi

volume for lane group i

Step 12: Delay calculation for the intersection


The intersection delay is calculated as the weighted delay for each approach.

dA VA
d I = ----------------------- VA
where
dI

mean delay per vehicle for intersection I

dA

delay for approach

VA

volume for approach

Step 13: Level of Service calculation


For the computation variant HCM 2000, the level of service is defined as a value which is
based on the mean delay of the node.
LOS

Mean delay/vehicle

0 10 sec.

10 20 sec.

20 35 sec.

35 55 sec.

55 80 sec.

80 + sec.

In HCM 2010, the level of service is automatically classified as F, if v/c (volume/capacity ratio)
exceeds the value 1.
For the variants ICU 1, ICU2, and Circular 212, the level of service is defined through the
saturation v/s (volume/saturation flow rate) of the node:
PTV AG

241

Chapter 5: User model PrT

LOS

volume/saturation flow rate

0.000 - 0.600

0.601 - 0.700

0.701 - 0.800

0.801 - 0.900

0.901 - 1.000

>1.000

Step 14: Mean queue length calculation per lane group


Queue lengths are also calculated by the HCM 2000 method. In HCM 2010, the method differs.
For this description, please refer to section 31-4, page 31-67 et seqq.
The equation for the calculation of the mean queue length is as follows:
Q = Q1 + Q2

where
Q

mean queue length maximum distance measured in vehicles the queue extends on
average signal cycle

Q1

mean queue length for uniform arrival with progression adjustment

Q2

incremental term associated with random arrival and overflow to next cycle

Step 14a: Calculation of the number of residual vehicles after cycle 1


Q1 represents the number of vehicles that arrive during the red stages and during the green
stages until the queue has dissipated.
vi C
g
------------ 1 ----i
3600
C
Q 1 = PF2 ---------------------------------------------gi
1 min ( 1, X i ) ---C

where
PF2

progression factor 2

vi

volume of lane group i per lane

C
gi

cycle time

Xi

volume/capacity ratio of lane group i

effective green time of lane group i

1 R g----i 1 v----i
P C

s i
PF2 = ---------------------------------------------------- 1 g----i 1 R v----i
P s

C
i

242

PTV AG

Chapter 5.5: Impedances at node

where
PF2

progression factor 2

vi

volume of lane group i per lane

C
gi

cycle time

si

saturation flow rate for lane group i

RP

platoon ratio based on lookup table for arrival type

effective green time of lane group i

Step 14b: Calculate second-term of queued vehicles, estimate for mean overflow queue
Q b 2 8 k i X i 16 k Q b
Qb
Q 2 = 0.25 c i T ( X i 1 ) + ----------- + X i 1 + ----------- + --------------------- + ------------------------
2
ci T
ci T
c i T
(c T )
i

where
T
k
Qb

Analysis period (usually 0.25 for 15 minutes)

ci

capacity for lane group i

adjustment factor for early arrival


initial queue at start of period (default 0)

k = 0.12 I (sigi / 3,600) 0.7 for fixed-time signal


k = 0.10 I (sigi / 3,600) 0.6 for demand-actuated signal
I

upstream filtering factor (set to 1 for isolated intersection)

Step 15: Calculation of the queue length percentile


After calculating the mean back of queue, the percentile of the back of queue is calculated as
follows:
Q------

P3
Q % = Q P1 + P2 e

where
Q
percentile

PTV AG

average queue length

pre-timed signal

actuated signal

70%

P1

P2

P3

P1

P2

P3

85%

1.2

0.1

1.1

0.1

40

90%

1.4

0.3

1.3

0.3

30

95%

1.5

0.5

1.4

0.4

20

243

Chapter 5: User model PrT

percentile

pre-timed signal

98%

1.6

1.0

actuated signal
1.5

0.6

18

1.7

1.5

1.71.7

1.0

13

Saturation flow rate adjustment factors


We now return to the calculation of the saturation flow rate (see "Saturation flow rate
calculation by lane group" on page 236) which involves several adjustment factors.

Step 6 a: Calculate lane width adjustment factor


fw = 1 +

(W 12 )
30

where
fw

lane width adjustment factor

mean lane width ( 8) (ft)

This method differs in HCM 2010. For a description, please refer to HCM 2010, page 18-36.

Step 6b: Calculate heavy goods vehicle factor


f HV =

100
100 + % HV (ET 1)

where
fHV

adjustment factor for heavy goods vehicles

%HV
EP

percentage of HGV per lane group


passenger car equivalent factor (2.0 / HV)

Step 6c: Calculate approach grade adjustment factor


fg = 1

%G
200

where
fg

adjustment factor for approach grade

%G

approach grade as percentage (-6 % to +10 %)

Step 6d: Calculate parking adjustment factor


fP is calculated as follows:

18 N m
N 0.1 -----------------3600 f = -----------------------------------------N

244

PTV AG

Chapter 5.5: Impedances at node

where
fp

parking adjustment factor (1.0 if no parking, otherwise 0.050)

N
Nm

number of lanes in lane group


number of parking maneuvers per hour (only for right turn lane groups) (0 to 180)

In Visum, enter fP which is calculated by the formula, as attribute ICA parking directly at the
node leg.

Step 6e: Calculate adjustment factor for position to city center


fa = 0.9 if link is in the city center (CBD), otherwise 1.0

where
fa

adjustment factor for position

CBD

indicates a central business district

Step 6f: Calculate bus stop blocking factor

f bb

14.4 N
N ----------------------B3600
= --------------------------------N

where
fbb

bus stop blocking adjustment factor ( 0.05)

N
NB

number of lanes in lane group


number of bus stop events per hour (does not apply to left turn lane groups) (0 to 250)

In Visum, enter fbb which is calculated by the formula, as attribute ICA bus blockage directly
at the node leg.

Step 6g: Calculate lane utilization adjustment factor


vg
f Lu = --------------vg 1 N

where
fLu

adjustment factor lane utilization

vg

unadjusted (input) volume for lane group g

vgl

unadjusted (input) volume for lane with highest volume in lane group (veh per hour)

For this adjustment factor, an HCM lookup-table is regarded (HCM 2000: table 10-23 on page
10-26; HCM 2010: table 18-30 on page 18-77). Alternatively, lane attribute values can be used
(ICA user-defined utilization share and ICA use user-defined utilization share).

PTV AG

245

Chapter 5: User model PrT

Step 6h: Calculate right turn adjustment factor


1.0 - (0.35) P RT for single lane approach

or

= 0.85
for exclusive right turn lane

or
1.0 - (0.15) P
RT for shared right turn lane

f RT

where
fRT

right turn adjustment factor ( 0.05)

PRT

proportion of right turn volume for lane group

The calculation according to HCM 2010 differs. For shared lanes, the adjustment factor is no
longer explicitly calculated. For more details, please refer to HCM 2010, page 18-38.

Step 6i: Calculate left turn adjustment factor


The left turn adjustment factor is the most complex of the factors. Here, HCM 2000 and HCM
2010 differ significantly. For the description, please refer to HCM 2010, page 18-38 and pages
31-30 to 31-37.
The calculation is simple for protected left turns. However, if there is permitted phasing, then
the equation is quite complex. It is as follows:

f LT

0.95 for exclusive left turn lane (protected phasing)

= ------------------------------------- for shared left turn lane (protected phasing)


1.0 + 0.05 P LT

see equations below for permissive phasing

where
fLT

adjustment factor for left turns

PLT

proportion of left turn volume for lane group

For permitted staging, there are five cases. When there is protected-plus-permitted staging or
permitted-plus-protected staging, the analysis is split into the protected portion and the
permitted portion. The two are analyzed separately and then combined. Essentially this means
treating them like separate lane groups. Refer to the HCM for how to split the effective green
times among the protected and permitted portions.
1. Exclusive lane with permitted phasing use the general equation below
2. Exclusive lane with protected-plus-permitted phasing use 0.95 for the protected portion
and the general equation below.
3. Shared lane with permitted phasing use the general equation below
4. Shared lane with protected-plus-permitted phasing use the equation above for protected
phasing portion and the general equation below for the permitted portion
5. Single lane approach with permitted left turns use the general equation below

246

PTV AG

Chapter 5.5: Impedances at node

The general equation for calculating fLT for permitted left turns is below. Note that this is not the
exact HCM 2000 equation since there are a few different versions depending on the situation
shared/exclusive lane, multilane/single lane approach, etc. But the equation is similar
regardless of the situation. This general equation is the equation for an exclusive left turn lane
with permitted phasing on a multilane approach opposed by a multilane approach.
The equation is basically the percentage of the time when lefts can make the turn times an
adjustment factor. The adjustment factor is based on the portion of lefts in the lane group and
an equivalent factor for gap acceptance time that is based on the opposing volume. The
calculation of the percentage of the time when lefts can make the turn is a function of the
opposing volume and their green time. The equation is as follows:
gu
1
f LT = ----- --------------------------------------------
g 1 + P L ( E L 1 1 )

( f LTmin f LT 1 )

fLTmin = 2 (1 + PL) / g
(N 1) g
P L = 1 + ----------------------------------------g u ( E L 1 + 4.24 )
gu = g - gq (if gq 0, else gu = g)
v olc qr o
-t
g q = ---------------------------------------------------------------0.5 [ v olc ( 1 qr o ) g o ] l

where

PTV AG

fLT

Global adjustment factor for left-turns

fLTmin

Minimum value for adjustment factor

g
gu

Effective non-protected green time for left-turn lane group

PL

Share of left-turns using lane L

EL1

Through equivalent for non-protected left-turns (veh/hr/lane) (look-up value depends on


conflict flow volume)

gq

Effective non-protected green time, while left-turns are blocked completely and the spill-back
of the conflict flow is reduced

go

Effective green time for conflict flow

N
volc

Number of lanes in lane group

No

Number of lanes in the lane group of the conflict flow

vo

Corrected conflict flow

fLUo

Lane utilization factor for conflict flow

qro

Opposing queue ratio = max[1 - Rpo (go / C), 0] (Rpo = look-up value depends on ArrivalType)

tl

Loss time for left-turn lane group

Effective non-protected green time for left-turns crossing a conflicting flow

vo C
3600 N o f LU

Corrected conflict flow per lane per cycle = --------------------------------------o

247

Chapter 5: User model PrT

The opposing volume is calculated from the signal groups that show green while the subject
lane group has green. To calculate the opposing volume for a subject lane group, the entire
opposing volume is used even if there is an overlap.
The permitted left movement calculation does not need to be generalized to 4+ legs since only
one opposing approach is allowed. If more than one opposing approach is coded, an error is
written to the log file.

Step 6j: Calculate pedestrian adjustment factors for left and right turns
The computation of the factors for left-turning and right-turning pedestrians and bicyclists is a
considerably complex operation. It is performed in four steps. For the computation, the bicycle
volumes of the legs are regarded and the pedestrian volumes of the crosswalks. A traffic flow
has potential conflicts with two crosswalks on the outbound leg. These two crosswalks head for
the opposite directions.
Note: At a leg which is a channelized turn no conflicts occur between right turn movements
and pedestrians.
Step 1: Determination of the pedestrian occupancy rate OCCpedg.

The pedestrian occupancy rate OCCpedg is derived from the volume. The following applies:

1
C
2
C
v pedg = min 5000, v ped -----1 + v ped -----2

gp
gp
v pedg 2000, if v pedg 1000
OCC pedg =
0.4 + v pedg 10000, else

Here, vpedg is the pedestrian flow rate, v1pedg and v2pedg are the pedestrian volumes of the
crosswalks, C is the cycle time of the signal control and g1p and g2p indicate the duration of
the green for the pedestrians.
Note: In the HCM2000 it is implicitly assumed, that the green for the left turn movements
and the green for the pedestrians start at the same time. In Visum, this is not the case,
however. Thus, the following distinction of cases applies in Visum: If the pedestrian green
time overlaps (or touches) the green or amber stage for vehicles, an existing conflict is
assumed. In this case, the duration of the green of the pedestrian signal group is fully
charged. Otherwise it is assumed, that there is no conflict. In this case, gp = 0 is assumed.
Step 2: Determination of the relevant occupancy rate of the conflict area OCCr

Here, three cases are distinguished:

Case 1: Right turn movements without bicycle conflicts or left turn movements from
one-way roads

In this case, the following applies:


OCCr = OCCpedg

Decisive for left turns from one-way roads is, that there is no opposite vehicle flow.

248

Case 2: Right turn movements with bicycle conflicts

PTV AG

Chapter 5.5: Impedances at node

Here, straight turns of bicyclists are assumed.


C
v bicg = min(1900, v bic ----)
g
OCCbicg = 0.02 + vbicg / 2700
OCCr = OCCpedg + OCCbicg - (OCCpedg)(OCCbicg)

Here, vbicg is the bicycle flow rate, vbic is the bicycle volume, C is the cycle time of the signal
control, g is the effective green time of the lane group, and OCCbicg is the conflict area's
occupancy rate caused by bicyclists.

Case 3: Other left turn movements

These are left turn movements which do not originate from a one-way road. Here, a
distinction of cases is made for the values gq and gp. gq is the clearing time of the vehicle
flow on the opposite leg, and gp is the green time for the conflicting pedestrians. The
following applies:
gp = max(g1p, g2p)

Case 3a: gq gp

In this case, the calculation is shortened and the following applies


fLpb = 1.0

Pedestrians and bicyclists are irrelevant here, since the left turn movements have to wait
until the vehicle flow on the opposite leg is cleared.

Case 3b: gq < gp

The following applies:


gq
OCC pedu = OCC pedg 1 0.5 -----
gp
OCC r = OCC pedu [ e

( 5 3600 ) v 0

Here, OCCpedu is the occupancy rate of pedestrians after the clearance of the vehicle flow
on the opposite leg, and OCCpedg is the pedestrians occupancy rate.
Step 3: Determination of the adjustment factors for pedestrians and bicyclists on permitted
turns ApbT

Here, two cases are distinguished with regard to the values Nturn which is the number of
lanes per turn and Nrec, which is the number of lanes per destination leg.

Case 1: Nrec = Nturn

Here applies ApbT = 1 - OCCr

Case 2: Nrec > Nturn

Here, vehicles have the chance to give way to pedestrians and bicyclists. The following
applies:
ApbT = 1 - 0.6 OCCr

PTV AG

249

Chapter 5: User model PrT

Step 4: Determination of the adjustment factors for the saturation flow rates for pedestrians
and bicyclists fLpb und fRpb.

fLpb is the adjustment factor for left turns, and fRpb is the adjustment factor for right turns.
The following applies:
fRpb = 1 - PRT (1 - ApbT) (1 - PRTA)
fLpb = 1 - PLT (1 - ApbT) (1 - PLTA)
PRT and PLT represent the proportions of right turn and left turn movements in the lane
group, and PRTA and PLTA code the permitted shares in the right and left turn movements
(each referring to the total number of right turn and left turn movements of the lane group).

5.5.3.3

Two-way stop nodes

Notes: For the description of this control type, please refer to HCM 2000, chapter 17, in HCM
2010 refer to chapter 19. In most instances, the calculation complies with HCM 2000.
Especially the explicit U-turn handling has been added.
In Visum, two-way nodes are modeled by the control types two-way stop and two-way
yield. In the HCM, the description refers to two-way stop nodes. Basically, the computation
is the same. The only difference is the determination of wait times in step 8.
Nodes of the signalized control type are also calculated according to the method for yieldcontrolled nodes, if no SC has been allocated or the SC has been turned off.
The two-way stop analysis method is based on the gap acceptance theory. The basic idea is
to calculate potential capacities for all movements, and then subtract capacity from these
movements based on movement rank (priority). The calculation flow chart looks like displayed
in illustration 62.

250

PTV AG

Chapter 5.5: Impedances at node

Inputs
Geometry
Volumes
%HGV, Ped Vol

Gap & Follow-Up


Times
Basics
Adjustment Factors

Volume
PHF
Identify Conflicts

Potential Movement
Capacity

Capacity Analysis
Delay, LOS, Queues

Illustration 62: Method of calculation at two-way stops

If you use the HCM 2000 operations model for two-way stop nodes, the Visum attributes in
table 73 will have an effect. Make sure that they are set to realistic values prior to running the
analysis.
Network objects

Attribute

Description / Effect

Link

Share of HGV

HGV share is used in the steps 3 + 4. A value which applies


to all turns originating from this link.

Link

Slope

Used in step 3

Node

ICA peak hour factor


volume adjustment

Factor for the initial volume adjustment to peak volume;


volumes are divided by both node and turn adjustment
factors

Geometry

All

Geometry data of lanes, lane turns and crosswalks

Turn

ICA peak hour factor


volume adjustment

Factor for the initial volume adjustment to peak volume;


volumes are divided by both node and turn adjustment
factors

Turn

ICA Preset critical gap Critical gap value of your choice

Turn

ICA Use preset critical


gap

Optionally, you can overwrite the critical gap, used in step 3


Activate this option, to use the critical gap set.

Turn

ICA Preset follow-up


time

Follow-up time value of your choice

Table 73: Input attributes for the calculation of two-way stops

PTV AG

251

Chapter 5: User model PrT

Network objects

Attribute

Turn

ICA Use preset follow- Optionally, you can overwrite the follow-up time, used in step
up time
4
Activate this option, to use the follow-up time set.

Description / Effect

Lane

ICA Preset critical gap Critical gap value of your choice

Lane

ICA Use preset critical


gap

Optionally, you can overwrite the critical gap, used in step 3.


The analogous value of the turn is not used.
Activate this option, to use the critical gap set.

Lane

ICA Preset follow-up


time

Follow-up time value of your choice

Lane

ICA Use preset follow- Optionally, you can overwrite the follow-up time, used in step
up time
4. The analogous value of the turn is not used.
Activate this option, to use the follow-up time set.

Table 73: Input attributes for the calculation of two-way stops

Output is available through the same attributes as for signalized nodes (table 72). Additionally,
the calculated critical gap and follow-up time data is provided.
The method works with movements (Left, Through and Right) at each approach. Each
movement is ranked according to table 74.
Rank
1

Major Through
Major Right
Pedestrian passage minor flow

Major Left
Minor Right
Pedestrian passage major flow
Major Left priority to gaps in the opposing flow
Minor Right priority to gaps in the flow of the right-most lane of the major flow
Pedestrians Priority to any other flow

Minor Through

Minor Left

Table 74: Ranking of movements

Note: HCM 2010 also regards U-turns on major flows. They are given rank 2. If the calculation
is based on HCM 2010, the U-turn related setting in the procedure parameters will not affect
these U-turns.

Step 1: Flow rate (volumes) calculation for each movement


The 15 min peak flow rates (as calculated from the PHF adjustment) are used as the adjusted
movement volumes.

Step 2: Conflicting flows for each movement


In addition to calculating the volumes for each movement, the conflicting volumes for each
movement for each approach must be calculated.

252

PTV AG

Chapter 5.5: Impedances at node

Notes: Rank 1 movements do not have conflicting flows since they have the highest priority.
Mainly, rank 1 movements are excluded from the analysis, with the exception of one
additional evaluation (see "Calculation of the critical vol/cap ratio for the entire intersection"
on page 238).
According to HCM 2010, pocket lanes for left turns (rights for left-hand traffic accordingly) in
the major flow are dealt with separately.
Only nodes with three or four legs are described in the HCM. In Visum, also multi-leg nodes
can be calculated. The 'Uncontrolled' rule is applied to conflicting flows between minor legs
which are not separated by a major leg.
For left-hand traffic, the right-hand calculation is performed symmetrically.
For right-hand traffic, the following example models the conflict flow of a left turn on a major
flow:

Volume through traffic in opposing direction + volume right turns in opposing direction
(does not apply, if right turns in opposing direction are separated by a channelized turn and
need to attend a yield sign or a stop sign) + pedestrian volumes minor flow crossing

The table 75 shows the equations for conflicting volumes.


Movement

Conflicting flows

Major Left

OT + OR* + ToP

Minor Right

JT/N + 0.5JR* + FrP + ToP

Minor Through

2JL + JT + 0.5JR* + FrP + ToP + 2JLF + JTF + JRF*

Table 75: Calculation of the conflicting volumes

where
O

Opposite direction

Through

Right

Left

Number of through lanes

Major

Minor

Far (for minor through/left turns the second major flow encountered)

ToP

Approach (to) with pedestrian crosswalk

FrP

Exit (from) with pedestrian crosswalk

There is a number of cases where the conflicting volume is adjusted:

PTV AG

If the major flow (right) is separated by a channelized turn and needs to attend a yield sign
or a stop sign then this flow will not be considered in the conflicting volume calculation for
other flows..
If the major flow has more than one lane, only the right lane volume of the major flow (= vol
/ num through lanes) applies as conflicting, for minor right and minor left turns.
If the major flow has a right turn lane, then the right turns of the major flow do not count for
the conflicting volume.

253

Chapter 5: User model PrT

For left turns from the minor flow, the right turn volume of the opposing direction does not
count for the conflicting flow, if the destination link of the two turns has more than one lane.

Notes: Apart from the U-turns, the HCM 2010 differs from HCM 2000 in subtle differences.
For the determination of conflicting flows, please refer to HCM 2010, pages 19-9 to 19-14.
The HCM does not regard bending two-way stop/yield cases. In this case, conflicting flows
are determined according to Brilon and Weinert, 2002.

Step 3: Critical gap calculation for each movement


The critical gap is the time an average driver would accept in order to merge with traffic.

Example
Sarah needs 4 seconds of space between vehicles to make her left turn and merge with other
traffic safely.
The critical gap equation is:
tcx = tcb + (tcHVPHV) + (tcGG) - tcT - t3LT

where
tcx

critical gap for movement x

tcb

base critical gap (see table 76)

tcHVPHV

adjustment factor for heavy vehicles percent heavy vehicles

tcGG

adjustment factor for grade grade (as a decimal)

tcT

two stage adjustment factor (currently set to 0 for one stage modeling)

t3LT

Critical gap adjustment factor for geometry

The other adjustment factors are:


tcHV = 1, for two - lane major street
2, for four - lane major street

0.1, for minor right

tcG = 0.2, for minor left and through


1, otherwise

t3 LT = 0.7 , for minor left at T - intersection

0, otherwise

The base values for the critical gap are calculated as shown in table 76.
Movement

Base critical gap value tcb


< 4 lanes major flow

4 + lanes major flow

Major Left

4.1

4.1

Minor Right

6.2

6.9

Minor Through

6.5

6.5

Minor Left

7.1

7.5

Table 76: Base values for the critical gap

254

PTV AG

Chapter 5.5: Impedances at node

If the calculated values differ from the observed values, manually set values per turn can be
used.

Step 4: Follow-up time calculation for each movement


The follow-up time is the extra time needed for a second car to also take the gap.

Example
Suppose Frank was waiting behind Sarah in the intersection. If he turns just after Sarah, he
would need a follow-up time of 2 seconds, rather than another 4 seconds to be able to merge
safely with other traffic. So, if the gap between vehicles was at least 6 seconds, both Sarah and
Frank could safely make their turns.
The follow-up time equation is:
t fx = t fb + t fHV P HV

where
tfx

follow-up time for movement x

tfb

base follow-up time (table 77)

tfHVPHV

follow-up time adjustment factor for heavy vehicles percent heavy vehicles

The other adjustment factors are:


0.9 for two-lane major street
t fHV =
1.0 for four-lane major street

Follow-up times are calculated according to table 77.


Movement

Base follow-up time value tfb

Major Left

2.2

Minor Right

3.3

Minor Through

4.0

Minor Left

3.5

Table 77: Follow-up times

If the calculated values differ from the observed values, manually set values per turn can be
used.

Step 5: Calculate the potential (or ideal) capacity for each movement
The potential capacity is the capacity which is achieved if this movement uses all potential
gaps (i.e. no higher ranking movements take up the gaps). Furthermore, it is assumed that
each movement is made from an exclusive lane. The potential capacity is defined as follows:
e (vcxtcx 3600 )
c px = vcx
1 e vcxt fx 3600

PTV AG

255

Chapter 5: User model PrT

with
cpx

potential capacity for movement x (veh/hr)

vcx

conflicting flow for movement x (conflict/hr)

tcx

critical gap for movement x

tfx

follow-up time for movement x

Step 6: Calculate movement capacity taking into account impedance effects


Higher ranking movements impede lower ranking movements capacities since vehicles
making higher ranked turns can use the available gap space before the lower ranked
movements. Therefore, we adjust the potential capacity by an adjustment factor to yield the
movement capacity. The movement capacity equation is as follows:
c mx = c px

i Movements with greater rank than movement x

p vi

j Impeding pedestrian movements

p pj

where
cmx

movement capacity for movement x (veh/hr)

cpx

potential capacity for movement x (veh/hr)

pvi = 1

P pj

vi
cmi = probability impeding vehicle movement i is not blocking subject movement

wv j ----SP
= 1 ---------------- = probability impeding ped movement j is not blocking subject movement
3600

vi

volume movement i

vj

volume pedestrian flow j (peds/hr)

w
SP

lane width (ft), standard value 12 ft.


pedestrian walking speed (ft/s), standard value is 4 ft/s

Since the calculation depends on higher rank movement capacities the calculation proceeds
from the top down (from rank 1 to rank 4 movements). Impeding vehicle and pedestrian
movements for each subject movement are listed in table 78:
Movement

Rank

Impeding movements

Major Through

None

Major Right

None

Major Left

ToP

Minor Right

FrP, ToP

Minor Through

JL, JLF, FrP, ToP

Minor Left

JL, JLF, OT, OR, FrP, ToP

Table 78: Impeding movements

256

PTV AG

Chapter 5.5: Impedances at node

where
J

Major

Minor

Opposite direction

Through

Right

Left

Far (for minor through/left turns the second major flow encountered)

ToP

Approach (to) with pedestrian crosswalk

FrP

Exit (from) with pedestrian crosswalk

Step 6a: Calculate adjustment for impeding major left turns


There is also an adjustment factor for major left if it does not operate from an exclusive lane.
The equation uses a default saturation flow rate. It is as follows:
1 p vJL
p vJL' = 1 ------------------------------------v JT v JR
1 ------+ -------s JT s JR
where
pvJL

modified probability of impeding maJor left

pvJL

unmodified probability of impeding maJor left

vJT

volume major through

vJR

volume major right (0 if exclusive right turn lane)

sJT

sat flow major through (1700 standard)

sJR

sat flow major right (1700 standard)

Note: Please refer to HCM 2010 page 19-20, for the description of a short pocket lane on the
major flow scenario.

Step 6b: Calculate adjustment for minor left turns


In addition, there is a special adjustment for minor lefts (rank 4). The equation is below.
Basically the major lefts and the minor through is precalculated and then adjusted. The
adjusted value is then used in conjunction with the remaining minor right and pedestrian
probabilities.
p

ii

= p vJL p vJLF p vIT


ii

i
ii
ii
p
p = 0.65 p --------------+ 0.6 p
ii
p +3
i

p vR 4 = p p vIR p pIP p pJP

where

PTV AG

257

Chapter 5: User model PrT

pvJL

probability of impeding maJor left near

pvJLF

probability of impeding maJor left far

pvIT

probability of impeding minor through

pvR4

probability minor left (rank 4)

pvIR

probability minor right (rank 2)

ppIP

probability minor pedestrian

ppJP

probability major pedestrian

Step 7: Capacities for movements that share lanes


The calculations so far assume that each minor movement operates out of an exclusive lane.
When there is a shared lane, a combined capacity is calculated for those movements which
share a lane.
CSH =

vi

c i

where
CSH

shared lane capacity

vi

volume minor street movement i

cm

movement capacity minor street movement i

Note: Note that the upstream signal and platoon flow adjustments are currently omitted from
the calculation. The same applies for the two-stage gap acceptable adjustment, as well as for
the flared approach adjustment.

Step 8: Calculate delay


The calculation of control delay is defined as follows:
vx
3600
------------- ------2
v
c
c
v
x
x
mx
mx
d x = 3600
------------- + 900 T ------- 1 + ------- 1 + -------------------------- +5
c

c mx
c mx
450 T
mx

where
dx

mean delay per vehicle for movement x

cmx

capacity for movement (shared lane x, CSH)

T
vx

duration of analysis period (hr) (default 0.25 for 15 min)


movement volume (shared lane x, VSH)

A similar formula is used for the calculation of either two-way control type (yield or stop):

258

PTV AG

Chapter 5.5: Impedances at node

vx
3600
------------- ------vx
vx
c mx c mx
vx
3600

d x = ------------- + 900 T -------- 1 + -------- 1 + --------------------------- + 5 min --------, 1


c mx
c mx
c mx
c mx
450 T
2

Control delay per movement is aggregated to approach with a weighted (by volume) mean of
all approach movements/shared lanes. Mean approach delay is then aggregated to the entire
intersection with a weighted mean as well. The equations are the same as the ones for
signalized intersections.
Note that rank 1 movements get no delay. If, however, there is no exclusive left turn pocket,
then rank 1 movements may experience delay. There is therefore, an additional delay equation
for rank 1 movements when there are no left turns pockets on the major approaches. The
equation is as follows:

dR 1

v
( 1 p vJL ) d JL ----TN
----------------------------------------------if N > 1
=
vT + vR

(1 p ) d
if N = 1
vJL
JL

(5)

where
dR1

delay rank 1 vehicles (s/veh)

N
pvJL

number of through lanes per direction of the major flow

dJL

delay to major left (s/veh)

vT

shared through lane volume (for multilane sites, only the volume in the shared lane)

vR

shared right turn lane volume (for multilane sites, only the volume in the shared lane)

probability for an adjustment factor impeding major left (5)

This delay is then substituted by the zero delay of rank 1 movements when calculating
approach and/or intersection delay.

Step 9: Level of Service


Level of Service is then simply defined as displayed in table 79 based on intersection delay.
LOS

Mean delay/vehicle

0 10 sec.

10 15 sec.

15 25 sec.

25 35 sec.

35 50 sec.

50 + sec.

Table 79: Allocation of a LOS to the mean delay per vehicle

PTV AG

259

Chapter 5: User model PrT

Note: For LOS analyses, HCM 2010 additionally takes into consideration whether the
capacity was exceeded. If this is the case, always level F of service will be allocated (HCM
2010, page 19-2).
The intersection queue length calculation is:

Q 95 x

3600 v x
------------- -------2
c mx
v
c mx c mx
vx
x
= 900 T -------- 1 + ------- 1 + -------------------------- ------------

3600
c mx
c mx
150 T

where
Q95x

queue length 95th percentile for movement x (veh)

cmx

capacity for movement (shared lane x, CSH)

T
vx

duration of analysis period (hr) (default 0.25 for 15 min)

5.5.3.4

movement volume (shared lane x, VSH)

All-way stop

Note: For the description of this control type, please refer to HCM 2000, chapter 17, in HCM
2010 refer to chapter 20. The calculations described in HCM 2010 and HCM 2000 are
identical.. HCM 2010 additionally includes the guidelines for queue length calculations (HCM
2010, page 20-17), which is missing in HCM 2000. Furthermore, the volume/capacity ratio is
regarded for the LOS calculation. In case of overload, automatically level F is assigned.
The HCM 2000 All-Way stop controlled (AWSC) capacity analysis method is an iterative
method. The model looks at all possible scenarios of a vehicle either being at an approach or
not being at an approach. Based on the input volumes the probability of each scenario
occurring is calculated as well as the mean delay. The v/c ratio is calculated for each scenario
which in turn impacts the others. Therefore, an iterative solution is needed to find the capacity
of each approach.
Unlike the signalized method, which works with signal groups, or the TWSC method, which
works with movements, the AWSC model works with lanes by approach.
The basic calculation is described in the flow chart in illustration 63. The user inputs
intersection geometry and volumes, along with a couple of additional attributes such as PHF
and %HGV. The volumes are adjusted and allocated to the lanes. The next step is to calculate
the saturation (capacity) follow-up time adjustment factors. Then the departure follow-up times
(i.e. the mean time between departures for a lane at an approach) are calculated based on all
the combinations of the probability states. This departure follow-up time for each lane for each
approach is dependent on the other approaches and so it is calculated in an iterative manner.
Once a converged value is found, then the service time, mean delay and LOS can be
calculated.

260

PTV AG

Chapter 5.5: Impedances at node

Inputs
Geometry
Volum es

Volume
PHF
Lane volumes

Base Headway
Adjustments

Probability States

Departure H eadway

Final D egree of
Utilization

Service Time and


C apacity
Delay and LOS

Illustration 63: Calculation process for an All-Way stop node

If you use the HCM operations model for All-Way stop nodes, the following Visum attributes in
table 80 will have an effect. Make sure that they are set to realistic values prior to running the
analysis.
Network object

Attribute

Description / Effect

Link

ShareHGV

Proportion of heavy goods vehicles, used in follow-up times


adjustment. A value which applies to all turns originating from this
link.

Node

ICAPHFVolAdj

Initial volume adjustment to peak period. Then, volumes are divided


by both node and turn adjustment factors.

Geometry

All

Geometry information on lanes, lane turns and crosswalks

Turn

ICAPHFVolAdj

Initial volume adjustment to peak period. Then, volumes are divided


by both node and turn adjustment factors.

Table 80: Input attributes for an All-Way stop node

Output is available through the same attributes as for signalized nodes (table 71).

PTV AG

261

Chapter 5: User model PrT

The first step is to PHF adjust the volumes by lane by movement by approach. In addition the
% heavy goods vehicles by lane by movement by approach are also input if available. Since in
Visum volumes are specified by movement and not by lane by movement, they are first
disaggregated per lane according to a standard method.
The next step is to calculate the follow-up time adjustment factors for each lane. The
calculation applies as follows:
hadj = hLTadj pLT + hRTadj pRT + hHVadj pHV

where
hadj

follow-up time adjustment

hLTadj

follow-up time adjustment for left turns

hRTadj

follow-up time adjustment for right turns

hHVadj

follow-up time adjustment for heavy vehicles

PLT

proportion of left-turning vehicles on approach

pRT

proportion of right-turning vehicles on approach

pHV

proportion of heavy vehicles on approach

The adjustment factors are listed in table 81.


Number of lanes of the subject approach

Adjustment factor

Saturation

Mean follow-up time

LT

RT

HV

0.2

-0.6

1.7

0.5

-0.7

1.7

Table 81: Adjustment factors

After calculating the follow-up time adjustment factor the departure follow-up time is calculated
in an iterative manner. It involves five steps.

Step 1: Calculate combined probability states probability


P( i) =

j P ( a j )

where
P(i)
P(aj)

probability for combination i

aj

1 or 0 depending on lane type j (see table 82)

probability of degree-of-conflict (DOC) for combination i lane type j

This probability states calculation has a few parts. For each lane type j the P(aj) is calculated.
P(aj) is calculated based on a lookup table (table 82).

262

PTV AG

Chapter 5.5: Impedances at node

aj

Vj (volume conflicting approach)

P(aj)

>0

Xj

>0

1 - Xj

Table 82: Probability states calculation of degree-of-conflicts

Notes:
If iteration is 1, then Xj = (Vj hd) / 3,600

If iteration is > 1, then Xj = min(1,(Vj hd) / 3,600)

Initial value hd = 3.2 s

Value aj is taken from the DOC table (table 83). This table contains all the combinations of 0
and 1 per lane for each approach. For two lanes per approach it looks like displayed in table 83
(see exhibit 17-30 in the HCM 2000 for the full table).
i

DOC case (Ck)

Number of
vehicles

Oppsoing
approach
L1

Left
(subject approach)

Right
(subject approach)

L2

L1

L2

L1

L2

64

There are 64 combinations for 4 legs each with 2 lanes.

Table 83: Excerpt from the DOC table for two lanes per approach

The combined probability states probability P(i) is then calculated for each row (i) for each
column (lane type) (j). To calculate P(i) we take the product of all probabilities of each opposing
lane and each conflicting lane P(aj). The result P(i) = P(aj) is the probability state for row (i).

Step 2: Calculate probability state adjustment factors


After calculating P(i) for each case (i), an adjustment for each DOC case needs to be
calculated. The adjustment accounts for serial correlation in the previous calculation due to
related conflict cases. For DOC case (Ck), the adjustment equations are:

PTV AG

263

Chapter 5: User model PrT

P( C1 ) = P( 1 )
4
P( C2 ) = P( i )
2
10
P( C3 ) = P( i )
5
37
P( C4 ) = P( i )
11
64
P( C5 ) = P( i )
38
adjP( C1 ) = a [ P( C2 ) + 2 P( C3 ) + 3 P( C4 ) + 4 P( C5 )] / n
adjP( C2 ) = a [ P( C3 ) + 2 P( C4 ) + 3 P( C5 ) P( C2 )] / n
adjP( C3 ) = a [ P( C4 ) + 2 P( C5 ) 3 P( C3 )] / n
adjP( C4 ) = a [ P( C5 ) 6 P( C4 )] / n
adjP( C5 ) = a [ 10 P( C5 )] / n
where
a
n

0.01 (or 0.00 if no serial correlation)


number of non-zero cases (i) for each DOC case (at most n = 1 for C1, 3 for C2, 6 for C3, 27 for
C4 and C5)

Step 3: Calculate adjusted probability


P(i) = P(i) + adjP(i)

where
P(i)
P(i)
adjP(i)

adjusted probability for case i


probability of degree-of-conflicts for case i
probability adjustment factor case i

Step 4: Calculate saturation follow-up time


hsi = hadj + hbase

where
hsi

saturation follow-up time by DOC case i

hadj

follow-up time adjustment by lane

hbase

base follow-up time by DOC case i

For each DOC case i, the base follow-up time hbase is taken from a lookup table which is based
on the particular DOC case (1 5) and geometry group (table 84).

264

PTV AG

Chapter 5.5: Impedances at node

Number of lanes
Subject
approach

Opposing
approach

Conflicting
approach

Intersection type

Geometry group

4 leg or T

4 leg or T

4 leg or T

3a / 4a

3b

4 leg

4b

1-2

1-2

4 leg or T

1*

1*

4 leg or T

4 leg or T

Table 84: Lookup table base follow-up time

Note: * If subject is 3 lanes and either opposing or conflicting approach is 1 lane then
geometry group 5, else geometry group 6.
The model is generalized for 3+ lanes in order to apply it to 4+ leg intersections. The extension
is that these 4+ leg cases are geometry group 6.
The table 85 shows the saturation follow-up time base values.

Geometry group

DOC case

Number of
vehicles (Sum of
the [0,1] for the
case)

1
2
>=3

1
2
>=3

2
3
4
>=5

3
4
5
>=6

3.9

4.7

5.8

7.0

9.6

3.9

4.7

5.8

7.0

9.6

3a

4.0

4.8

5.9

7.1

9.7

3b

4.3

5.1

6.2

7.4

10.0

4a

4.0

4.8

5.9

7.1

9.7

4b

4.5

5.3

6.4

7.6

10.2

4.5

5.0
6.2

6.4
7.2

7.6
7.8
9.0

9.7
9.7
10.0
11.5

4.5

6.0
6.8
7.4

6.6
7.3
7.8

8.1
8.7
9.6
12.3

10.0
11.1
11.4
13.3

Table 85: Base values for the saturation follow-up time

The DOC case is dependent on the 64 types of a 4 leg intersection. Nodes with more than 4
legs are first collapsed to four legs.

PTV AG

265

Chapter 5: User model PrT

Step 5: Calculate departure follow-up time


hd =

i I P' ( i ) hsi

where
hd

departure follow-up time for lane

hsi

saturation follow-up time for each i in I

P(i)
I

adjusted probability for each i in I


Row of table 1

These five steps are repeated until the departure follow-up time values converge (change is <
0.1). Now, the calculated departure follow-up time hd differs from the original value. Thus, the
next iteration will return a different result.
Now that the departure follow-up time for each lane is calculated, service time and capacity can
be calculated. The service time is calculated as follows:
t = hd - m

where
t
hd

Service time

move up time (2.0 s for geometry groups 1-4 and 2.3 s for groups 5-6)

Departure follow-up time

The capacity is calculated as follows: the volume of the subject lane is incremented until its
degree of utilization (vjhd)/ 3,600 is 1.0. The volume of the other approaches is held constant.
At this point, the subject lanes volume value is taken to be the subject lanes capacity.
Capacity is therefore dependent on the input volumes for each approach.
The search for capacity is slow in a linear implementation. Thus a binary search is performed
with an upper bound of 1,800 vphpl.
Mean delay per lane is calculated from the equation below. The weighted mean delay for an
approach is calculated based on lane volume weights. Intersection average delay is calculated
based on the weighted mean by approach volumes. The equations are the same as the ones
for signalized intersections.
hd x
2
d x = t + 900 T x 1 + ( x 1 ) + ----------------+5
450 T

where

266

dx

Mean delay per vehicle for lane x

t
T
x

Service time

hd

Departure follow-up time

Duration of analysis time slot (hr) (default 0.25 for 15 min)

Vh
3600

d
Utility rate -------------

PTV AG

Chapter 5.5: Impedances at node

Level of Service is defined as a lookup based on intersection delay (table 86).


LOS

Mean delay/vehicle

0 10 s

10 15 s

15 25 s

25 35 s

35 50 s

50 + s

Table 86: Determining the LOS based on the mean delay per vehicle

The proposed extension for 4+ legs is to combine multiple lefts or rights into one left or right by
adding the number of lanes together when calculating conflicting flows. For example, when
there are two conflicting lefts for a subject approach, one with one lane and one with two lanes,
they are merged into one conflicting left with three lanes. This allows the existing framework to
be used. It probably slightly understates the delay, but it will work within the existing framework
and will result in additional delay for additional legs.

5.5.3.5

Roundabouts according to the HCM 2010 method

For this analysis method, please refer to HCM 2010, chapters 21 and 33. It is similar to the one
for two-way stop nodes and mainly differs from it in the following points:

Determining the conflict flows follows the geometry of the roundabout.


The standard values for gaps differ due to changed visibility conditions. Also this calculation
is performed on the basis of lanes, not on the basis of turns.
This method is available for one- and two-lane approaches (plus one optional bypass lane).
The Visum method used for three- or multiple-lane approaches is not described in the
HCM. Visum distributes the volume across the lanes as for two-way stop nodes.

The calculation process is illustrated by illustration 64.

PTV AG

267

Chapter 5: User model PrT

In p u ts
V ol um es

Vo lu m e
In co m i ng l eg s
C on flic ting v ol um e s

T im e g a p s
C ri ti c al g aps
F ol l ow -up t im es

C ap a city

W a itin g tim e
Q u eu e l en g th

Illustration 64: Calculation process for roundabouts according to HCM 2010

If you use the HCM 2010 operations model for roundabout nodes, the Visum attributes in
table 87 will have an effect. Make sure that they are set to realistic values prior to running the
analysis.
Network objects

Attribute

Description / Effect

Geometry

All

Geometry data of lanes, lane turns and crosswalks

Node

ICAPHFVolAdj

Turn

ICAPHFVolAdj

Factor for adjustment of initial volumes to peak volumes.


Then, volumes are divided by both node and turn
adjustment factors.

Leg

Center island length

Length of center island

Leg

Center island width

Width of center island

Leg

Channelized turn
length

Length of channelized turn

Leg

Has splitter Island

Indicates whether a leg has a splitter island (yes/no)

Leg

Length of splitter
island

Length of the splitter island


Note
Value entered is used if the Has splitter island attribute is
activated.

Leg

Splitter island width

Wdith of splitter island


Note
Value entered is used if the Has splitter island attribute is
activated.

Leg

Has bypass lane

Indicates whether the leg has a bypass lane (yes/no)

Table 87: Input attributes for roundabout nodes according to HCM 2010

268

PTV AG

Chapter 5.5: Impedances at node

Network objects

Attribute

Description / Effect

Leg

Share of bypass
volume

Proportion of right turns (left-hand traffic: left turns), which


use a bypass lane for the turn movement.
Note
This information is used, if the Has bypass lane attribute is
activated.

Lane

ICA Preset critical gap Critical gap value of your choice

Lane

ICA Use preset critical


gap

Optionally, you can overwrite the critical gap, used in step 4


The analogous value of the turn is not used.
Activate this option, to use the critical gap set.

Lane

ICA Preset follow-up


time

Follow-up time value of your choice

Lane

ICA Use preset follow- Optionally, you can overwrite the follow-up time, used in step
up time
5 The analogous value of the turn is not used.
Activate this option, to use the follow-up time set.

Table 87: Input attributes for roundabout nodes according to HCM 2010

Output is available through the same attributes as for signalized nodes (table 72).
The calculation method according to HCM 2010 consists of twelve consecutive steps. Here,
the description is reduced to the most important steps.

Step 1: Calculate flow rates (volumes) for each turn


The turn volumes are converted by multiplying them with the peak hour factors of the turns and
the node in values for the 15 minute peak.

Step 2: Calculating traffic flows for each lane and conflicting volumes for each
approach
All calculations are based on the traffic flows and conflicting volumes at each approach. These
flows are derived from the turn volumes (in illustration 65 for a roundabout with four
approaches designated with v1 to v12).

PTV AG

269

Chapter 5: User model PrT

Illustration 65: Approaching flows at a four-leg roundabout

For the distribution of the volumes to the lanes please refer to HCM 2010, pages 21-14 and 2115.

Example
The flow from the south is the sum of turn volumes v7 + v8 + v9. The conflicting flow which
applies to this flow is however the sum v1 + v2 + v10. This approach can be applied to
roundabouts with a countless number of approaches. U-turns can also be considered in the
same way, if you want to integrate them in the ICA calculation.
If an approach has more than one lane, the total inflow is distributed on lanes.
1. If only one lane is permitted for left turns, its volume is the sum of all volumes of left turns.
2. If only one lane is permitted for right turns, its volume is the sum of all volumes of right turns.
3. The remaining volume is distributed to all lanes in such way, that they all have the same
volume if possible.

Step 3: Capacity
The capacity of an approach depends on various factors: the number of lanes per approach
and the number of lanes in the roundabout and whether a lane is a bypass lane. For each of
the cases, predefined formulas can be used (HCM 2010, equations 21-1 to 21-7). This is the
basic formula:
c = 1130 e

Bv

Here B equals 0.001 for one-lane and two-lane entry roads to single-lane roundabouts. For
single-lane approaches to two-lane roundabouts B equals 0.0007. Two-lane approaches to
two-lane roundabouts use the following values for B: 0.00075 for the inner-most (let) lane, and
0.0007 for the right lane. For bypass lanes, with one conflicting exit lane, B is assumed to be
0.001. 0.0007 is used if there are two conflicting exit lanes.

270

PTV AG

Chapter 5.5: Impedances at node

Users with detailed knowledge of critical gaps and follow-up times can replace these formulas.
For the control type 'roundabout', critical gap and follow-up time are set by lane. Turn-related
values of this attribute are not regarded. For the extended computation, the capacity is derived
from the following data (HCM 2010, page 33-3):
Bv

c = Ae
------------A = 3600
gap f

gap
gap c -----------f
2B = ---------------------------3600

where
c
v
gapc

capacity in PCU/h

gapf

follow-up time in s

conflicting flow in PCU/h


critical gap in s

Visum uses the following standard values: 4 s for the critical gap and 3 s for the follow-up time.
You can optionally overwrite both values by lane.
Pedestrians have a bearing on the capacity. For a detailed description, please refer to HCM
2010, pages 21-16 and 21-17.
To the turns, the approach capacity is distributed in proportion to the volume. The result is
stored in the turn attribute ICA final capacity.

Step 4: Wait times


The mean wait time on a lane of an approach arises from the following values:
3600
------------ v-2
v
3600
v
c
c + 5 min -v- ,1

d = ------------ + 900 T -- 1 + -- 1 + -----------------c


c
c
c
450 T

d
c
v
T

mean delay in s/PCU


lane capacity in PCU/h
lane volume in PCU/h
observation period in h

The mean delay of a turn is the volume weighted mean of the mean delay of lanes used. The
result is saved in the turn attribute tCur.
Note: For turns with lane turns without allocated signal group, tCur is set to zero.

Step 5: Queue lengths


The mean queue length on a lane of an approach arises from the following values:

PTV AG

271

Chapter 5: User model PrT

Q 95

3600- v-
2 -----------c 3600
v
v
c

= 900 T -- 1 + 1 -- + -------------------- ------------c


150 T
c
c

where
Q95

95% percentile of queue length in PCU

c
v
T

lane capacity in PCU/h


lane volume in PCU/h
observation period in h

The attribute ICABackOfQueueForDefPerc is the maximum of the Q95 percentiles for the
lanes used.

Step 6: Level of Service (LOS)


LOS per lane of an approach is defined as a classification of the mean delay (table 88).
LOS

Mean Delay [s / PCU]

0 - 10

>10 - 15

>15 - 25

>25 - 35

>35 - 50

>50

Table 88: LOS per lane based on the mean delay

The HCM does not determine the calculation of the LOS per approach, turn or node. In these
cases Visum calculates the LOS on the basis of the volume weighted mean delay. If the
volume exceeds the capacity, the LOS is automatically set to F.

5.5.3.6

Roundabouts according to the TRL/Kimber 2010 method

This analysis method regards approach capacity as a function of geometry and the conflicting
volume in roundabouts. On the basis of numerous observations, this function was calibrated to
British roundabouts.
The illustration 66 shows the calculation process for roundabouts according to the TRL/Kimber
method.

272

PTV AG

Chapter 5.5: Impedances at node

Inputs
Geometry
Volumes

Volume
Incoming legs
Conflicting volumes

Capacity

Waiting time
Queue length

Illustration 66: Calculation process for roundabouts according to the TRL/Kimber method

In Visum, the geometry of the roundabout is described through leg attributes. These attributes
are only important, if the node is a roundabout and if TRL/Kimber is selected as analysis
method. In all other cases, the parameters are ignored at ICA calculation. The meaning of the
parameter is illustrated in illustration 67, which has been taken from the DMRB guideline TD
16/93. For a better comparison with this guideline, the common English original attributes and
abbreviations are specified in the tabular overviews. Another parameter describes the
temporal variability of the inflow.

PTV AG

273

Chapter 5: User model PrT

Illustration 67: Description of the node geometry for the TRL/Kimber model

The table 89 shows the additional input attributes at legs for calculation according to TRL/
Kimber.
Name

DMRB definition

ICA inscribed circle


diameter

Value
type

Value range
(Default value)

Meaning

ICAInscribedLength
CircleDiameter (D)

10 - 200 m (40
m)

External diameter of the


roundabout. For
asymmetric roundabouts
specify the radius related to
the environment of the
respective approach.

ICA entry width

ICAEntryWidth (e)

Length

3 - 20 m (7 m)

Width of the entry directly at


roundabout

ICA approach half width

ICAApproachHalfWidth (v)

Length

2 - 15 m (3.5
m)

Road width of the approach


link without pocket

ICA flare length

ICAFlareLength
(L)

Length

1 - 100 m (20
m)

Half length of the approach


between the points where
ICAEntryWidth and
ICAApproachHalfWidth are
measured.

Table 89: Input attributes for calculation according to the TRL/Kimber method

274

PTV AG

Chapter 5.5: Impedances at node

Name

DMRB definition

Value
type

Value range
(Default value)

Meaning

ICA entry radius

ICAEntryRadius (r) Length

1 - 1,000 m (35 Circle radius which


m)
tangentially approximates to
the outer circle of the
roundabout and the outer
boundary of the approach.

ICA entry angle

ICAEntryAngle () Integer

0..180 (45)

ICA grade separation

ICAGradeSeparation (SEP)

Length

0 - 100 m (0 m) Distance between approach


and exit of the same node
leg. For regular
roundabouts specify 0 m.
This implies the roundabout
is not grade-separated.
With values > 0 you
describe the approaches of
grade-separated expanded
roundabouts, where the
entry is far away from the
exit of the same leg.

ICA Kimber Hollis c-factor ICAKimberHollisC

Double

0 .. 10 (1.0)

See illustration 67

In the queue length formula


by Kimber-Hollis, the cfactor describes the
variability of the inflow

Table 89: Input attributes for calculation according to the TRL/Kimber method

These attributes are only important, if the ToNode of the link has the controller type
roundabout, i.e. the link represents an approach to a roundabout. In all other cases the
attributes are ignored.
The output attributes correspond to those for signalized intersections (table 72).

Step 1: Traffic flows and conflicting volumes for each approach


All calculations are based on the traffic flows and conflicting volumes at each approach. These
traffic flows are derived from the turn volumes. All volumes are expressed in PCUs.

Step 2: Approach capacities


For roundabouts with RDistanceExit = 0, the following applies:
k ( F f qc )
Cap =
0

if F > f q c
else

where

PTV AG

Cap
qc

approach capacity in PCU/h

k
F
f

1 - 0.00347 ( - 30 ) - 0.978 [(1/r) - 0.05]

conflicting flow in PCU/h

303 x
0.21 t (1 + 0.2 x)

275

Chapter 5: User model PrT

t
M

1 + 5 / (1 + M)

x
S

v + (e - v) / (1 + 2 S)

e(D - 60)/10
1.6 (e - v) / L

The remaining variable descriptions refer to the attributes of the geometry description.
Different from the above mentioned, the following applies for roundabouts with RDistanceExit
> 0:
Cap =1.004F - 0.036SEP - 0.232 qc + 14.35 - f qc(2.14 - 0.023 qc)

where all sizes as above, however Cap and qc in PCU/min.


The capacity of each lane is distributed proportionally to the volume of the turns. The result is
saved in PCU/h in the turn attribute ICAFinalCapacity.

Step 3: Queue lengths


The queue length of an approach results from the Kimber and Hollis formula (Kimber, Hollis
1979), (Kimber, Daly 1986).
2

( 1 ) ( T ) + ( 1 L 0 )T 2 ( 1 C ) ( L 0 + T )
A = -------------------------------------------------------------------------------------------------------------------------T + 1 C
4 ( L 0 + T ) ( T ( 1 C ) ( L 0 + T ) )
B = -----------------------------------------------------------------------------------------------T + 1 C

1
2
L = --- ( A + B A )
2
where
L

expected queue length at the end of the observation period in PC units

approach capacity in PCar units/h

T
L0

length of the observation period in h

C
v

Variation factor KVKimberHollisC

= v / = Saturation

initial queue length (in Visum always 0)

approach volume in PCar units/h

Visum uses the formula modified in (Kimber, Hollis 79) for increased accuracy.
The mean queue length of each turn is equal to the mean queue length of its approach and is
stored in the turn attribute ICAQueueLength.

Step 4: Delays
The mean control-based wait time per approach results from the Kimber and Hollis formula
(Kimber, Hollis 1979), (Kimber, Daly 1986).

276

PTV AG

Chapter 5.5: Impedances at node

T
1
J = --- ( 1 ) --- ( L 0 C + 2 )
2

L0 + 1
4 T
1
K = --- --- ( 1 ) + --- TC --------------- ( 1 C )
2

1
2
d = --- ( J + K J )
2
where
d

mean permitted delay in the observation period in h

approach capacity in PCar units/h

T
L0

length of the observation period in h

C
v

Variation factor KVKimberHollisC

= v / = Saturation

initial queue length (in Visum always 0)

approach volume in PCar units/h

The mean permitted delay of a turn is equal to the mean permitted delay of its approach and is
saved in the turn attribute tCur.
Visum evaluates, like in Step 3, the increased accuracy modified formula by Kimber and Hollis.

Step 5: Level of Service (LOS)


The concept of a LOS is not mentioned in the Kimber model. To create consistency within ICA
and because the RFC (Ratio Flow to Capacity) skim was criticized as being insufficient, Visum
still defines a LOS per approach as a classification of the mean delay (table 90).
LOS

Mean Delay [s / PCU]

0 - 10

>10 - 15

>15 - 25

>25 - 35

>35 - 50

>50

Table 90: LOS for calculation according to Kimber based on the mean delay

Visum calculates the LOS of the entire node accordingly, on the basis of the volume weighted
mean delay of all approaches.

5.5.4

Signal time optimization


Within the scope of the intersection capacity analysis using ICA, you can optimize the signal
times for individual signalized junctions in two ways:

PTV AG

Green time optimization (see "Green time optimization" on page 279)


Cycle and green time optimization (see "Signal cycle and green time optimization" on
page 281).

277

Chapter 5: User model PrT

Furthermore, with signal coordination you can optimize the time intervals between more than
one light signal control in the network (see "Signal coordination (Signal offset optimization)" on
page 281).
Note: Optimization regards only those nodes (main nodes), whose effective control type =
signalized. Optimization does not regard those nodes (main nodes) whose SC has been
turned off or to which no SC has been allocated.

5.5.4.1

Data model for SC cycle and green time optimization

The following attributes of network objects are relevant for the cycle and green time
optimization:
Network object type

Attribute

Description

Signal control and


subordinate objects

All attributes which


describe signal times

Signal times and stage distribution in the initial state

SC

Reference to signal
coordination groups

Signal coordination
group

Cycle time family

At cycle time optimization with procedure


parameters UseCycleTimeFamily=True, only one
member of the cycle time family of the coordination
group is selected as a new cycle time.

SC

ICA maximum cycle time


for optimization
ICA minimum cycle time
for optimization

At cycle time optimization with procedure parameter


UseCycleTimeFamily=False the new cycle time is
selected from the interval between these two
attributes.

SC

Optimization method

0 = no signal time optimization for the signal control


at this node
1 = only green time optimization
2 = cycle and green time optimization

SC

Turned off

If the SC has been turned off, no signal time


optimization will be calculated for the node (main
node).

Turn

The attribute for the


design hourly volume set
in the procedure
parameters

Turn volumes

Node model and


subordinate objects

All geometry attributes

Lane allocation at node

Optimization is controlled by the following procedure parameters (components of the


procedure parameters for intersection capacity analysis):

278

Procedure parameter Data type (Standard)

Description

Automatic green time Boole (False)


optimization

Are the signal times always optimized within the ICA


calculation? If yes, it depends on the SC attribute
Optimization method which optimization method is
applied to which SC.

PTV AG

Chapter 5.5: Impedances at node

Procedure parameter Data type (Standard)

Description

UseCycleTimeFamily Boole (True)

At cycle time optimization with procedure parameters


UseCycleTimeFamily=True, only one member of the
cycle time family of the coordination group (if available)
is selected as a new cycle time.

Precision of
computation

5.5.4.2

Seconds or tenths of a Via this parameter you can decide whether seconds or
second
tenths of a second are permitted as green time start and
end.

Green time optimization

The predefined cycle time applies as predefined for pure green time optimization.

Green time optimization for stage-based signal controls


The following steps are necessary for calculating the green time split:
1. Deconstruct approaches into lane groups (already calculated for capacity analysis).
2. Calculate adjusted volume and saturation flow rate for each lane group (already calculated
for capacity analysis).
3. For each stage in the signal timing plan, determine the critical lane group.
4. Allocate green time based on critical lane group volume/saturation flow rate ratios.
5. Check that the allocated green times meet all the constraints.
Green time split is calculated as follows:
Gi =

(v s )ci
Gte
(v s )ci
i

where
Gi

effective green time for stage i

(v/s)ci

ratio of volume v and saturation flow rate s for critical lane group ci in stage i

Gte

total effective green time for cycle

The total effective green time for a cycle is the same as the cycle time deducting all intergreens
between consecutive stages. The intergreen between two stages is zero, if the stages share
signal groups. Otherwise, intergreen is given by the attribute Default intergreen of the signal
control.
Each stage must also maintain the minimum green time, which is given by the Minimum green
time attribute of the signal control. If the calculated green time for a stage is less than the
minimum green time, then the green time split equation is rerun with the stage below its
minimum green time omitted. The omitted stage is assigned the minimum green time. That
minimum green is subtracted from the total effective green time and the green time split is
recalculated.
As a result of optimization, new values are assigned to the attributes Green time start and
Green time end of the stages.

PTV AG

279

Chapter 5: User model PrT

Green time optimization for signal group-based signal controls


The optimization of signal group based signal controls results from the following steps of the
procedure for stage-based signal controls:
1. Fictitious stages are generated from the current greentimes of the signal groups.
Visum first defines set T of all switching points from the attributes Green time start and
Green time end of all signal groups and sorts these in ascending order. For each interval
between consecutive times ti and ti+1 in T generate a stage which contains all signal groups
which have been released during [ti ; ti+1).
2. The fictitious stage-based signal control is optimized as above (see "Green time
optimization for stage-based signal controls" on page 279).
3. The signal group green times are read from the optimal stage distribution.
Green time for each signal group results from the green time of all stages which contain the
signal group. Because all of these are neighboring stages due to construction, there is only
one green time for the signal group.

Green time optimization for external signal controls and RBC


Visum can be used to optimize Vissig signal controls. Stages have to be defined for this signal
control. Optimization of non-stage based Vissig controls or controls of the RBC type will be
made available later.
To exclude selected stages from the optimization to keep their lengths as set in the original
signal timing plan, select 'true' for the attribute Pseudo stage of these stages.
Visum executes the following steps to calculate the green time split:
1. With the current signal timing plan, execute an ICA calculation and determine both
saturation flow rate and volume for each lane group.
2. Solve the linear optimization problem:

Max z

P, G( l ) P sl tP z ql l L
min

tP tP

tP C

P
P

where
L

set of all lane groups

cycle time

sl

saturation flow rate of lane group l

ql

volume of lane group l

tP

green time duration of stage P

min

tP

280

minimum greens of stage P

PTV AG

Chapter 5.5: Impedances at node

The first secondary condition expresses that the share z of the volume per lane group
depends on the green times of the stages provided for this group. The share z is
maximized.
3. With the optimized signal timing plan, execute another ICA calculation.
4. If the total mean wait time has not improved, cancel the calculation and continue with step
5. If the saturation flow rates have changed, continue with step 2. Otherwise, continue with
step 5.
5. To the stages' attributes Green time start and Green time end, allocate the values
obtained from the recent optimum solution.

5.5.4.3

Signal cycle and green time optimization

If you select the Signal cycle and split optimization for a node, Visum calculates an optimal
cycle time for the signal control at the node and at the same time an optimal green time split for
this cycle time. If several (main) nodes belong to a signal control, then automatically all (main)
nodes of this signal control will be optimized.
The calculation includes the following steps:
1. Determine the set T of permitted cycle times at the SC. If the procedure parameter Use
cycle times of coordination groups is active and if the SC belongs to a coordination
group, then only cycle times of the coordination group's cycle time family are permitted.
Otherwise, any cycle time (integer [in seconds]) from the interval between the SC attributes
ICA minimum cycle time for optimization and ICA maximum cycle time for
optimization is permitted
2. To each permissible cycle time t from T the following applies:
Specify optimal green times g*(t) for predefined cycle time t.
Use ICA to calculate the total wait time at the node for g*(t).
3. As an optimal cycle time t* select the t with minimum total wait time. In addition, set the
optimal green time split g*(t*).
The ICA calculation of the total wait time at the node only provides valid values, if the sum of
critical v/s ratios is smaller than or equal to 1. To greater sums always t* = max(T) applies. If
the sum of the minimum green time and intergreens for all stages or signal groups are larger
than the calculated t*, t* is set to the smallest t of T which is larger or equal to this sum. If no
such t exists, t* is set to the sum independently of T.

5.5.4.4

Signal coordination (Signal offset optimization)

Signal cycle and split optimization always refers to individual signal controls. Signal offset
optimization, however, is used to optimize the offset between the signal times of neighboring
nodes in such a way, that vehicles can pass several consecutive signal controls on green. The
general aim is to minimize the total wait time for all vehicles at the signal control.
Notes: The method does not regard the attributes of the node geometry. Especially the stop
line position per lane is not taken into consideration.
Signal coordination dos not include signalized nodes or main nodes to which no SC has been
allocated or whose SC has been turned off.

PTV AG

281

Chapter 5: User model PrT

Example
We will demonstrate the task with the example network displayed in illustration 68.

Illustration 68: Example network for signal coordination

In the network in illustration 68 the six inner nodes have signal controls and the outer nodes are
only there to connect the four zones. Link and turn volumes result from an assignment. Lane
allocation is usually selected, so that at each approach of a node, a shared lane exists for the
straight and right turns and a 100 m long pocket for left turns additionally. Additional lanes are
only located at individual approaches with an especially large traffic volume. All SC have the
same signal times (illustration 69).

282

PTV AG

Chapter 5.5: Impedances at node

Illustration 69: Green time split at all nodes with succeeding left turns

With a cycle time of 80 s, straight and right turns each have a green time of 30 s. Signal groups
for left turns have 5 s more and are protected within this time.
Signal times and lane allocation are selected in such a way that the resulting capacity is
sufficient for all turns. Wait times can occur if neighboring SCs are badly coordinated. For this
example we first assume an offset time of 0 s for all SC. The assignment result illustrated by
link bars results as overlapping of seven paths and one of these is highlighted in the
illustration 70.

PTV AG

283

Chapter 5: User model PrT

Illustration 70: A path through the example network passes SCs at nodes 7003, 8003, 8002 and 9002

This route passes the signalized nodes 7,003, 8,003, and 9,002. Vehicles exiting node 7,003
in direction 8,003 form a group that starts at the beginning of the green time, i.e. at second 0.
Travel time tCur, on the link between 7,003 and 8,003, is 38 s. Without accounting for dispersal
of the group, the first vehicles reach node 8,003 at second 38. The distribution of the actually
driven speed by vehicles leads to a resolution of the original compact platoon (illustration 71).

Illustration 71: Progression quality for approach West at node 8003

284

PTV AG

Chapter 5.5: Impedances at node

On the left, the diagram shows the arrival rate by cycle second. The first vehicles arrive at
second 30. The arrival rate then steeply increases and decreases as of second 52. The signal
group to continue the journey also has a green time between second 0 and 30. The major part
of the platoon therefore reaches the node at red. The second diagram shows the
corresponding development of the queue length and the third diagram the resulting wait time
in vehicle seconds dependant on the arrival second. The total wait time across all arrivals is
19,069 vehicle seconds, which corresponds to a mean value of 39.20 s per vehicle. This is an
example for bad coordination.
At node 8,002, the situation is much more favorable (illustration 72).

Illustration 72: Progression quality for approach North at node 8002

The vehicle group again starts driving at second 0. The travel time on link 8,003 - 8,002, with
tCur = 41 s, is similar to before. However, the continuing signal group 4 for left turns, at node
8, has a green time from second 40 to second 75. Most of the vehicle group arrives during
green time. The queues are distinctly shorter and the total wait time is only 1,608.80 vehicle
seconds (mean: 4.37 s per vehicle).
In this simple example, the aim of signal coordination would be to change the offset between
nodes 7,003 and 8,003, so that the entire vehicle group arrived at 8,003 during green time. At
the same time, however, you would want to maintain the favorable offset between 8,003 and
8,0002. Because a convenient coordination should be achieved not only for one but several
paths (in the example, seven) simultaneously, signal coordination usually minimizes the total
wait time of all SCs by changing the offset times.

Model
Signal coordination in Visum can be used for optimizing SCs in a network, not only along a
linear corridor, as it corresponds with the traditional optimization of the progressive signal
system. This section describes how the optimization model is set up, which Visum solves by
using a standard procedure for mixed integer linear optimization. All attributes which describe
input and output of the procedure are summarized in the following section (see "Input attributes
with effect at signal coordination" on page 288).
Good coordination requires the SCs either have the same cycle times or that the cycle times
are at least in a simple ratio (for example 2:1). Furthermore, SCs have to be located close to
each other, otherwise the platoon will have broken up so heavily by the time it has reached the
next SC, that the arrivals will virtually be uniformly distributed and the wait time cannot be
influenced through the choice of the offset. It is therefore generally not sensible to coordinate

PTV AG

285

Chapter 5: User model PrT

all SCs in one network. You determine which SCs should be coordinated, by defining signal
coordination groups and assigning them SCs (see User Manual, Chpt. 2.40.14, page 633). By
default, SCs are not assigned to any signal coordination group and are not coordinated.
For each signal coordination group define the set of the cycle times which are permitted for the
corresponding SCs. Please make sure that the cycle times actually make coordination
possible. Two SCs with cycle times of 60 s and 65 s can generally not be coordinated because
the platoon in each cycle takes place at a different cycle second. Suitable cycle times therefore
have a small LCM (least common multiple), for example, the family { 60 s, 80 s, 120 s } with
LCM = 240 s. Signal coordination optimizes offset times for each signal coordination group
separately and takes those SCs into consideration with cycle times belonging to the permitted
cycle times of the group. SCs with deviating cycle times are ignored and logged in the message
file.
Important for coordination is the behavior of the vehicle platoon during the journey from one SC
to another. Visum determines platoons by analyzing the assignment results for one or more
selected PrT demand segments. From the saved paths of the assignment, Visum determines
how many vehicles on their way first pass signal group SG1 of the SC SC1 and then signal
group SG2 of the SC SC2. We call such a combination of two consecutive signal groups with
one volume a coordination path leg or shorter path leg.
A path leg is relevant for the coordination, if the following properties apply.

Path leg starts and ends at SC of the same coordination group


Path leg contains no nodes of controller type All-way stop
Path leg passes through node of controller type two-way stop only in the direction of the
major flow
Path leg does not pass through other signalized nodes
Travel time on the path leg is short enough, so that a significant platoon remains
(specification below)
No link along the path leg exceeds a threshold for the saturation

All conditions except for the first one are aimed at a platoon remaining along the path leg.
Optimization treats the traffic flows on all path legs interdependently. In each case it is
assumed that within a cycle all vehicles start as a platoon at the beginning of the green time.
This means, that beginning with the green time start, outgoing vehicles flow off with the
saturation flow rate qmax, until the volume per cycle has been exhausted. The following applies:
PCU
q max = 1900 ------------ N
h

Here, N is the effective number of lanes for the turn. If the green time duration is insufficient and
does not allow the volume allocated to a cycle from the assignment to exit with qmax, Visum
ignores the excess volume and logs this in the message file.
The platoon resolution, solely caused by different vehicle speeds, describes the platoon
development formula according to Robertson. This model discretely divides the time in
increments (in Visum of 1 s) and displays the number at time t, at which a vehicle arrives at
the end of a path leg as a function of the number at time t < t, at the beginning of the path leg
departing vehicle.
q' t + T = F q t + ( 1 F ) q' t + T 1

286

PTV AG

Chapter 5.5: Impedances at node

where
qt

the number of vehicles arriving at the end of the path leg in time step t

qt

the number of vehicles departing at the beginning of the path leg in time step t

1
F = -------------------with specified constants and
1 + T

travel time tCur on the path leg

For calculating queue lengths it is presumed that separate lanes of sufficient length exist for
separate signal groups at an approach. Visum generally assumes "vertical" queues for signal
coordination and does therefore not consider spillback upstream over several links or have an
effect on the capacity of the turns of other signal groups.
For the evaluation of the progression quality, Visum calculates a number of skims which are
used throughout literature. In the subsequent formulas CT determines the cycle time, GT the
green time and qt the number of vehicles arriving at a node in time step t.

t CT qt avg
t CT qt
Platoon index = ------------------------------------------- with avg = -----------------------CT
q
t

t CT

This size measures the "distance" of a volume profile of an equal distribution. The value varies
from 0 (equal distribution) to 2 (for a distinct platoon). A high value means that coordination is
worthwhile at this node, because the arriving vehicles are focused on part of the cycle time, so
that there is a chance of moving the green time there, by changing the offset time.
t GT qt
Vehicles at green = 100 ------------------------- .
qt
t CT

This size directly measures how well coordination works. It calculates which part of the volume
passes the node without stopping at the SC.

q
t GT t GT
------------------------ -------Platoon ratio =

CT
q
t CT t
The size also measures how well coordination works, whereas high values imply good
coordination. Especially high values are achieved when a large share of arrivals enter at green,
although the green ratio itself is smaller.
The platoon ratio PR is the basis for the important ArrivalType parameter in waiting time
calculations according to HCM.
1
2

3
ArrivalType =
4
5

PTV AG

if
if
if
if
if
if

PV < 0.5
0.5 PV < 0.85
0.85 PV < 1.15
1.15 PV < 1.5
1.5 PV < 2.0
2.0 PV

287

Chapter 5: User model PrT

Queue length queuet at a signal group to cycle second t results from the difference of
cumulative inflows and exit flows. For this calculation, Visum also calculates the delays of
travel times with specified arrival time in the queues and hence, the mean and total wait time.

Input attributes with effect at signal coordination


Signal coordination accesses the network objects and the input attributes displayed in table 91.
Note: Node geometry attributes such as the stop line position, for example, are not regarded
for signal coordination.
Network object

Attributes

Note

PrT paths

Volume

From assignment

Links, turns, main turns

A freely selectable
attribute

Is interpreted as travel time and will be summed up


for travel time calculation per path leg

SC with all components

All

Signal timing, cycle time, mapping of signal groups


and lane turns, selection of a reference SC that
has offset = 0.

Signal coordination
groups

Cycle time family and


assigned SC

Grouping of the SCs to be coordinated collectively

Table 91: Input attributes with effect at signal coordination

Output attributes at signal coordination


The effect of the signal coordination lies mainly in assigning the attribute offset of the
coordinated SC with an optimal value.
Alongside that, all skims listed above can be calculated for measuring the progression quality.
Their definitions first of all refer to a single path leg. In order to easier display results in a
network model, Visum aggregates the values of all skims on links and saves the results as link
attributes. Visum allocates the attributes at all approach links to signalized nodes which have
a volume of > 0. All link attributes for signal coordination results are contained in the table 92.
.

Name

Value type Value range

Meaning

SC coord vehicles on green

Double

0.0 .. 100.0

Number of vehicles which arrive during


green time [%]

SC coord platoon index

Double

0.0 .. 2.0

Definition see above

SC coord platoon ratio

Double

0.0 ..

Definition see above

SC coord arrival type

Integer

1 .. 6

Definition see above

SC coord wait time

Time

0 s ..

Total wait time [Vehicle seconds]


Note: For links to overloaded signal groups,
this value is set to 100,000 h.

SC coord maximum queue


length

Double

0.0 ..

Max. number of queued vehicles over all


cycle seconds [Veh]
Note: For links to overloaded signal groups,
this value is set to 100,000.

Table 92: Output attributes of links for signal coordination results

288

PTV AG

Chapter 5.5: Impedances at node

Note: By the name component 'SC coord', the attribute SC coord arrival typeis indicated as
signal coordination output attribute. It is not identical to the ICA arrival type attribute, which
is used as entry for ICA calculation. If you want to calculate the ICA impedance with an arrival
type which corresponds with the given offset time intervals, first perform the Signal offset
analysis and then copy the SC coord arrival type values to the ICA arrival type attribute.

Procedure parameters
Alongside the network object attributes, the procedure parameters listed in table 93 control
signal coordination.
Name

Value range (Standard)

Meaning

Automatic Analysis

Boole (True)

After signal coordination, the output link attributes


are automatically updated.

Coordination group set

Set of coordination groups Coordination is only carried out optionally for


(all)
selected signal coordination groups.

Demand segments set

Set of assigned
PrT_DSeg (all assigned
PrT_DSeg)

Optionally, path legs are only determined from


the assignment paths of selected demand
segments.

MaxSaturation

Double > 0 (80%), in


percent

If this saturation is exceeded on a path leg link,


the path leg is ignored for coordination, because
no platoon is retained with too high saturation.

MinPlatoonIndex

Double > 0 (0.4)

If the platoon index is below this threshold at the


end of the path leg, the path leg is ignored for
coordination, because the platoon is not distinct
enough.

RobertsonAlpha

Double > 0 (0.35)

Parameter for the platoon progression formula


according to Robertson

RobertsonBeta

Double > 0 (0.8)

Parameter for the platoon progression formula


according to Robertson

TravelTimeLinkAttr

numeric link attribute


(AddValue1)

When calculating the path leg travel time, for


each traversed link, TravelTimeLinkFac
TravelTimeLinkAttr is summed up

TravelTimeLinkFac

Double > 0 (1.0)

TravelTimeTurnAttr

Numeric turn attribute


(AddVal1)

TravelTimeTurnFac

Double > 0 (1.0)

TravelTimeMainTurnAttr

Numeric main turn


attributes (AddVal1)

TravelTimeMainTurnFac

Double > 0 (1.0)

MaxCalculationTime

Time

When calculating the path leg run time, for each


traversed turn, TravelTimeTurnFac
TravelTimeTurnAttr is summed up
When calculating the path leg run time, for each
traversed turn, TravelTimeMainTurnFac
TravelTimeMainTurnAttr is summed up
Calculation time for the solution of the
optimization problem is restricted. The best
solution found up to the specified time limitation,
is assigned.

Table 93: Procedure parameters for signal coordination

PTV AG

289

Chapter 5: User model PrT

Problem solution
To determine an optimal set of offset times per SC, Visum sets up a mixed integer linear
optimization problem. The deciding variables in this problem are the differences of the offset
times of neighboring SCs, the objective function is an in sections linearized approximation of
the wait time in dependency thereof. Secondary conditions express that the differences
between the offset times of adjacent SCs along each circle in the network have to be added to
an integer multiple of the cycle time.
A detailed description of the method is found in Mhring, Nkel, Wnsch 2006.

5.6

PrT skims
With the Calculate PrT skim matrix procedure the PrT skims which are listed in table 94 can be
calculated (see User Manual, Chpt. 5.8, page 1061). The abbreviations in parentheses
indicate the file extensions which are used by default for skim matrix output in version files.
t0-PrTSys (TT0)

TSys-specific travel time t0 in unloaded network

tCur-PrTSys (TTC)

TSys-specific travel time tCur in loaded network

AddValue1..3 (AD1 - AD3)

Sum of AddValue

Trip distance (DIS)

Distance covered from origin to destination

Direct distance (DID)

Direct distance between origin and destination zone

Speed v0-PrTSys (VP0)

TSys-specific speed v0 in unloaded network

Speed vCur-PrTSys (VPC)

TSys-specific speed vCur in loaded network

Toll (TOL)

Toll of traversed links

Impedance-PrTSys (IMP)

TSys-specific impedance in unloaded network

AddValue-TSys (ADS)

Sum of TSys-AddValue data

User-defined (UDS)

Flexible calculation of a mean attribute value per OD pair, the linkage of


attributes of different traversed network objects is also possible (see
"Using user-defined PrT skims" on page 1063)

Table 94: PrT skims

Calculating skims is either done via the best path as regards to the set criterion or via
aggregation from the paths of an assignment result calculated beforehand. In this case you can
select one of the aggregation functions listed in table 95.
Minimum impedance

Skim value calculated from the path with minimum impedance

Maximum impedance

Skim value calculated from the path with maximum impedance

Mean over paths

Skim value calculated as a mean over all paths

Mean over path volume

Skim value calculated as a mean over all paths weighted with the
corresponding path volume

Table 95: Aggregation functions for the skim data calculation

290

PTV AG

Chapter 5.7: Distribution of the traffic demand to PrT connectors

Moreover, the set of origin-destination relations for skims can be calculated, and also restricted
like the type of network objects which are included in the skim calculation.

5.7

Distribution of the traffic demand to PrT connectors


The distribution of PrT origin and destination demand onto PrT connectors can be done freely
or proportionally. In the case of proportional distribution, again two options are differentiated:
distribution of the total demand or distribution per OD pair (see "Distribution of demand of a
zone to the connectors" on page 47).

Free distribution
During route search, only the connector time is considered and traffic demand is distributed
without further constraints onto the routes with the lowest impedance.

Proportional distribution of total traffic


Before the route search is carried out, the share of total origin and destination traffic is
calculated for every zone whose demand is to be distributed proportionally. From this, a virtual
connector capacity (= proportion origin/destination demand) can be deduced for every
connector which modifies the impedance of the connectors during assignment in such a way
that proportional distribution is achieved. The correspondence between the distribution of the
assignment and the predefined values depends on the selected assignment procedure and the
selected VD function for connectors. A steep VD function should be used. In addition to this,
the connector times must not be too low so that the connector impedance has an effect on the
route search. When using this option, it should be noted, that the distribution may have very
different effects on the individual OD pairs. If the link impedance equals the displayed lengths,
practically all trips from zone 1 to zone 3 lead via node 2. The vast majority of trips from zone
1 to zone 2 however are made via node 1.

60 %

Zone3

Zone1

Zone2

40 %

1
Illustration 73: Example network for proportional distribution of the traffic demand

Example: Connector capacity determination for proportional distribution of the total traffic
(illustration 73)

Zone 1 has proportional distribution


Zone 2 has proportional or absolute distribution

PTV AG

291

Chapter 5: User model PrT

Zone 3 has proportional or absolute distribution


Travel demand from zone 1 to zone 2: 1,000 trips
Travel demand from zone 1 to zone 3: 400 trips
Origin demand zone 1: 1,400 trips
Connector zone 1 node 1: 40 % proportion
Connector zone 1 node 2: 60 % proportion
Capacity of connector zone 1 node 1 is 40 % x 1,400 = 560 trips
Capacity of connector zone 1 node 2 is 60 % x 1,400 = 840 trips
Steep VD function for connectors, for example BPR function with a = 1, b 4, c 1

Proportional distribution of each individual relation (MPA)


Alternatively, the proportional distribution can be applied to each OD pair. This leads to the
following distribution in the example above:

Example: determination of connector capacity for proportional distribution per OD pair:

Zone 1 node 1 zone 2 with 40 % 1,000 = 400 trips


Zone 1 node 1 zone 3: 40 % 400 = 160 trips
Zone 1 node 2 zone 2 with 60 % 1,000 = 600 trips
Zone 1 node 2 zone 3: 60 % 400 = 240 trips

5.8

Blocking back model


The blocking back model (pseudo-dynamic assignment, pa) fills the gap between merely static
procedures, which do not have any temporal reference and cannot determine congestionrelated wait times, and dynamic procedures that require long computation times. The
procedure is much faster than any dynamic assignment, requires less memory capacity and
can furthermore deliver information on congestion phenomena. The procedure can be applied
in conjunction with static assignment in order to estimate queue lengths and wait times in
oversaturated networks. In contrast to dynamic-stochastic assignment, it is suitable for
networks with > 50,000 links and only requires few additional data for temporal distribution of
the demand.
The general idea is to re-assign route volumes that were calculated with any static assignment
at an earlier stage. Output data of the procedure:

new volumes on links, connectors, (main) turns and (main) nodes


queue lengths on links and connectors
wait times on links

The original volumes of links, connectors and (main) turns resulting from the assignment are
stored with the following attributes:

Volume demand PrT with base


Volume demand DSeg
Volume demand PrT

Original node volumes can be found in the following attribute:

292

PTV AG

Chapter 5.8: Blocking back model

Volume demand PrT

The blocking back model is divided into two phases, the second phase is optional.

Phase 1 (congestion calculation)


Along a route, the demand share is passed on from one link to the next until a restricting
capacity has been reached. The following rules apply in this process.
1. The volume passing from one link to the next cannot exceed the capacity (PrT) of the link,
the capacity of the To node, and the capacity of the turn. For links, the amount of traffic
leaving the link counts (bottleneck at end of link).
2. The queue on a link can never exceed the stocking capacity of the link.
3. As soon as a queue forms on a link in some direction, no traffic can pass the link even if the
respective route does not lead across the bottleneck that is causing the congestion.
The fourth rule which limits the inflow of a link, directly results from this.
4. The inflow of traffic on a link is limited to the amount resulting from capacity plus stocking
capacity.

Phase 2 (precise wait time calculation)


Already in phase 1, wait times are calculated from the resulting queue lengths and the duration
of this phase. In the optional phase 2, more precise wait times are calculated by simulating also
the discharge of the congestion. New traffic is not imported, but rather the traffic stored in the
local queue lengths is distributed along the routes according to the same rules as in the first
phase. This is done in small time steps, where the capacities still limit the inflow. After each
step, the level of congestion is stored The second stage ends, when all local congestion is zero
and thus no traffic remains in the network. This results in a series of snap shots of the level of
congestion at different times which are then used to calculate a delay.

5.8.1

General notes on the blocking back model


The blocking back model is no independent assignment procedure, but it modifies the results
of previously run assignments or of the running assignment. As an option, the blocking back
model can be carried out together with an assignment (see User Manual, Chpt. 5.5,
page 1006).
The blocking back model only applies to PrT transport systems. Assuming that PuT transport
systems are either not affected by any congestion or that the timetables used already regard
the wait times. PuT-caused congestion on commonly used links can be neglected or can be
considered by a basic volume.
Since volumes of different PrT demand segments are summed up before entering the queue
length, all volumes are invariably converted into car units.
The following two operating modes are possible:

PTV AG

You can calculate the blocking back model post-processed following an assignment. It
therefore does not influence the route choice.

293

Chapter 5: User model PrT

Alternatively, you can execute the blocking back model in the external iteration of an
assignment procedure. The results are then included in the link impedance and therefore
in the route choice. This modus operandi is not recommended, since it significantly
downgrades the convergence of the particular assignment procedure. To take the blocking
back impact on the route choice into consideration during the assignment, you should
rather use the procedure Assignment with ICA (see "Assignment with ICA" on page 354).

In either case it can be combined with the following assignment procedures: Incremental,
Equilibrium, Equilibrium_Lohse, TRIBUT and any stochastic procedure. However, it cannot be
combined with a dynamic assignment procedure.
If an assignment has already been calculated for at least one demand segment, which is not to
be recalculated, the blocking back model is calculated prior to the execution of the assignment
of the already assigned demand segments. This is to ensure that the values for tcur and tw are
consistent with the current network status and to avoid that assignments with a blocking back
model share and those without are combined.
If the blocking back model is calculated as an integrative part of other procedures, one has to
differentiate between iterative procedures (Incremental assignment, Equilibrium_Lohse and
Stochastic assignment) one the one hand and balancing procedures (Equilibrium assignment
and TRIBUT) on the other hand. During those procedures running step-by-step a corrected
volume will always be calculated after the volume determination and also the wait times will be
calculated by the blocking back model. Then, in the i-th iteration, from the corrected volume a
new value tiCur will be calculated for the current travel time and the wait time tiw will be added.
i

t = t Cur + t w

As new value, the arithmetic mean Ti of all former ti is used, which is also considered in the
subsequent route search.
i

k = 0 t

k = 0 tCur + tw
k

T = --------------------- = --------------------------------------i+1
i+1

Here, t0Cur = t0 and t0w = 0 applies.


The consideration of earlier values guarantees the necessary attenuation and enforces the
procedures convergence. If only the current value would be taken into account when
calculating the impedances in the next iteration, the total traffic volume would shift back and
forth between alternative routes without converging towards a result.
The value returned for the wait time tw at links however, is just the wait time value determined
during the previous calculation of the blocking back model. In the case of convergence, it is
consistent with the times used in the assignment. The following applies:

For the calculation of the travel time tCurNew, using the corrected volume is necessary, since
the increase of the travel time above the capacity limit is no longer determined by volumedelay functions but modeled by explicitly calculated wait times.
If there is neither any congestion nor a decrease in the volume due to a flow-rate loss, tCur
= tCurNew and tw = 0 apply in any case. The impedance is unchanged compared to a
conventional assignment in this case.

294

PTV AG

Chapter 5.8: Blocking back model

If the blocking back model is integrated into an equilibrium assignment (not recommended), the
selected procedure is calculated first and the blocking back model is calculated subsequently
in an outer loop. Both methods are based on the fact that the volume of a link equals the total
volume of all routes traversing that link. For that reason a link-related modification of the
volume, as performed by the blocking back model would have no effect.
Instead, the result of the calculation of the blocking back model is used to modify the VD
functions of each link temporarily so that identical travel times result for unchanged network
volumes and for the changed network volumes with the original VD functions. These modified
VD functions can then be used for another iteration of an equilibrium assignment. If the network
volume has not changed, an equilibrium state has been reached which regards the modified
travel times tCur that result from the blocking back model. Otherwise a further iteration is carried
out, that includes blocking back model and assignment. As is the case with other methods, the
modified VD functions are averaged over several iteration steps in order to suppress the
alternation of the route choice between several alternatives.
The equilibrium state that is reached by this integrated calculation procedure is characterized
as follows: in due consideration of the changes to the travel times (and thus to the impedances)
which result from the volume calculated by means of the blocking back model, the travel time
(the impedance) is the same for each route of an OD pair.

Limiting capacity
According to rule 1, the traffic flow from link to link along a route is limited by the capacity of the
link and the capacity of the link's ToNode and the capacity of the turn during the blocking back
model calculation. In the blocking back model parameters you can select individually, whether
link and turn and node capacities are to be regarded. The settings have the following meaning:

Link capacity restricts the outflow per link. As threshold, either the link attribute Capacity
PrT can be used or the summed up Capacity PrT of the outgoing turns. The latter option
is only provided for compliance with out-dated versions. It is no longer recommended. It is
recommended to use the option Turn capacity instead.
Node capacity restricts the flow per node (sum of all turn volumes) to the node attribute
Capacity PrT. These node capacities are only regarded for traffic flows on secondary links
(tmodelspecial = true) towards the node. Traffic flows on major legs therefore also have an
effect on crossing routes via secondary links.
Turn capacity restricts the flow per turn to the turn attribute Capacity PrT.

These three options can be combined at will.


Furthermore you can decide by node, whether the global blocking back model parameter
settings are to be regarded; alternatively, a node-specific setting (node attribute Use preset
blocking back capacity settings = activated) can be used instead. The node-specific setting
is regarded for all turns via this node and for all links leading into this node. To regard the turn
capacity only at particular nodes, for example, then exclude the consideration of turn capacities
in the global blocking back model parameters and activate the attributes Use preset blocking
back capacity settings and Use turn capacity in blocking back at the particular nodes.

5.8.2

Procedure of the blocking back model


The procedure is divided into the following steps:

PTV AG

Determining the excess congestion factor

295

Chapter 5: User model PrT

Formation of congestion (phase 1)


Relief of congestion (phase 2) optional
Determining the wait times

Determining the excess congestion factor


Prior to the actual simulation of the queuing up, the excess congestion factor is calculated for
the network. In this process, the volumes and capacities of the links, nodes and turns for which
you have preset that they are to be regarded are taken into account.
For a single link L, the excess congestion factor Link(L) is given by
VolDem ( S )
Link ( L ) = ----------------------------------------------------------------------------------------------------------Cap ( L ) ScalingFactor q Basic volume ( L )

Here, VolDem(L) is the link volume resulting from assignment, Cap(L) is the PrT capacity of the
link, and ScalingFactor is the scaling factor for capacities from the blocking back model
parameters. Furthermore, VolBasic volume(L) is a basic link volume. You can select it in the
general procedure settings via PrT settings > Assignment.
Analogously, excess congestion factors Turn(T) and Node(N) are defined for turns T and nodes
N. Since basic volumes can only be preset for turns and links in Visum, the sum of the basic
volumes of the turns at the node is used as basic volume for nodes. Now, the excess
congestion factor of the network is the maximum of the excess congestion factors of all links,
nodes, and turns whose capacities are to be taken into account. It indicates by which factor the
(remaining) capacity in the network is exceeded at most.
The percentage of traffic corresponding to the reciprocal of this number can pass through the
network without any congestion. If 1, the procedure is not carried out. In this case, the
corrected volumes (Vol) equal the volumes calculated in the assignment (VolDem), thus no
congestion occurs.
If the denominator in the formula for the excess congestion factor calculation falls below 0 or
becomes 0 for a link or node or turn, there is no more free capacity available and the procedure
terminates.

Simulation phase 1 Formation of congestion


In phase 1, queue lengths on links and connectors are calculated and also the reduced
(compared to the original values) volumes of links, connectors and nodes. Thereto, we let
traffic flow into the network step by step along the routes resulting from assignment, and in
contrast to the previous assignment, the rules 1 to 3 are observed here. However, rule 3 is
weakened by the permeability factor P which determines the share that can pass existing
congestions. If P = 0, rule 3 is satisfied.
Let N be the number of shares for the volume distribution in phase 1. You can specify this
parameter in the procedure parameters for the blocking back model. In order to enforce rules
1 to 3, we iteratively propagate the N-th part of the route volume from the origin to the
destination until we reach a link on which a queue or another bottleneck (link, node, or turn) has
already formed for which the capacity is exceeded. This is carried out N times until all of the
traffic has flown into the network. In this case, that part of the volume is not added to the link
volume, but to the queue length.
Find below a detailed description of the procedure in phase 1. These are the most important
abbreviations used in this section:

296

PTV AG

Chapter 5.8: Blocking back model

VolDem

Volume demand: volumes from the assignment without consideration of withheld vehicles in
the blocking back model (i.e. if no blocking back model is calculated or no congestion occurs,
VolDem equals the volume Vol)

Vol
Cap
K
Q
P

(reduced) volume calculated in phase 1

Excess congestion factor

PrT capacity of a link, a turn or a node


Stocking capacity of a link
Queue length of a link (or connector)
Permeability of a link, describes the share of the flow that can pass existing queues

Firstly, the network is loaded with that portion of demand which does not cause congestions
yet. Then, the remaining demand flows into the network step-by-step. At first, the greatest
natural number n is determined, that satisfies n/N 1/. The general is then as follows:
Initialize Vol for all links, turns, nodes and connectors by entering 0.
Initialize Q or all links and connectors by entering 0.
For all links L and connectors C, load Vol(L)*n/N or Vol(C)*n/N, respectively.
For j = n+1 to N
For each demand segment
For each route R of the demand segment
Load VolDem(R) / N to route R.

Loading a volume flow to a route R with the n-th part of VolDem (flow) is performed as follows.
Let L0, L1, ..., Lk be the generalized links of a route, i.e. L0 is the origin connector, Lk is the
destination connector, and the real links are in between. Now, the traffic from the origin zone
flows via L0, L1, ..., Lk to the destination zone, at which the traffic flow is always limited by the
capacities of the links and turns and nodes and by congestions that might have formed.
Capacities bear limiting effects as described below. Let toNode(L) be the To node of a link L and
let Turn(Lj, Lj+1,T) be the turn from L to Lj+1 for the links L and T. Now, the flow from Lj to Lj+1
is limited by the capacity of Lj, and by the capacity of the To node of Lj, and by the capacity of
the turn from Lj to Lj+1.
Note: If you have decided that a particular capacity should not have an effect, then the
calculation assumes an infinite capacity. Connectors have an infinite capacity by definition.
The maximum volume maxFlow from Lj to Lj+1 then is
maxFlow(Lj, Lj+1) = min{Cap(Lj) ScalingFactor - VolBasic volume(Lj),
Cap(toNode(Lj)) ScalingFactor - VolBasic volume(toNode(Lj)),
Cap(Turn(Lj, Lj+1)) ScalingFactor - VolBasic volume(Turn(Lj, Lj+1))}

If the amount of in-flowing traffic on a link of the route exceeds the amount, that can flow off to
the next link, then the portion of traffic that keeps flowing depends on the remaining free
capacity:

PTV AG

297

Chapter 5: User model PrT

Function Load(R, flow):


For j = 0 to k-1
propagatingFlow = flow
If Q(Lj) > 0
propagatingFlow:= propagatingFlow * Permeability(Lj)
propagatingFlow:= min(propagatingFlow, maxFlow(Lj, Lj+1))
Vol(Lj) := Vol(Lj) + propagatingFlow
Vol(toNode(Lj)) := Vol(toNode(Lj)) + propagatingFlow
Vol(Turn(Lj, Lj+1)) := Vol(Turn(Lj, Lj+1)) + propagatingFlow
Q(Lj) := Q(Lj) + (flow - propagatingFlow)
Propagate queue backwards

Traffic that cannot flow into the next link is added to the queue length. If the queue on a link
exceeds the maximum stocking capacity K, then backups will arise on previous links of the
route. In that process, the backup has to be subtracted from the volume(s) of the previous
link(s) again (also nodes and turns are concerned), since this flow actually cannot have
reached the congested link being located ahead in the route course:
Function PropagateQueue(R):
propagatingQ = 0
For j = k-1 to 1
If Q(Lj) > K(Lj)
propagatingQ := Q(Lj) - K(Lj)
Q(Lj) = K(Lj)
Q(Lj-1) := Q(Lj-1) + propagatingQ
Vol(Lj-1) = Vol(Lj-1) - propagatingQ
Vol(toNode(Lj-1)) := Vol(toNode(Lj-1)) - propagatingQ
Vol(Turn(Lj-1, Lj)) := Vol(Turn(Lj-1, Lj)) - propagatingQ

After phase 1, nodes require a special treatment for the following reason: Though there are no
turns at connectors, connector nodes are loaded in the process. To achieve the state, that the
node volume = sum of all turn volumes at connector nodes after phase 1, the node volume of
connector nodes is recalculated from the turn volumes after the procedure.
We use a simple example with two routes to illustrate the procedure. Route 1 leads from A to
D, route 2 from B to C. Both routes have a volume VolDem of 200 vehicles. The volume is
distributed to the routes in four iteration steps with 50 vehicles each. The number of iteration
steps is based on the procedure parameter Number of shares for flow distribution in phase
1. For reasons of simplification, only the link capacity is considered as limiting capacity in the
example. Route 1 is always charged first. There is a bottleneck on route 1. On route 2, a
backup arises though this route does not traverse the bottleneck link.

298

PTV AG

Chapter 5.8: Blocking back model

Illustration 74: Blocking back model, phase 1: Formation of congestion Iteration steps 1 and 2.

In the first two iteration steps, each of the two routes is loaded with 50 vehicles. Queues do not
form yet (illustration 74).

Illustration 75: Blocking back model, phase 1: Formation of congestion Iteration step 3, route 1

Route 1: On the highlighted link, a bottleneck is located in iteration step 3. Due to the
insufficient stocking capacity of this link, the queue propagates to the preceding link
(illustration 75).

PTV AG

299

Chapter 5: User model PrT

Illustration 76: Blocking back model, phase 1: Formation of congestion Iteration step 3, route 2

Since there is now a congestion on the link in the middle, also the vehicles following route 2 get
stuck in the queue (illustration 76).

Illustration 77: Blocking back model, phase 1: Formation of congestion Iteration step 4, route 1

Another 50 vehicles are added to route 1 in iteration step 4. As the stocking capacity of the link
in the middle is fully exhausted, vehicles continue to propagate backwards (illustration 77).

300

PTV AG

Chapter 5.8: Blocking back model

Illustration 78: Blocking back model, phase 1: Formation of congestion Iteration step 4, route 2

The 50 vehicles with route 2 cannot even reach the link in the middle; they all get stuck in the
congestion on the first link (illustration 78).

Simulation phase 2: Relief of congestion


During the simulation phase 1, the local queue length of each link and corrected volumes have
been determined. If phase 2 is not calculated (optional), the wait times for phase 1 are
calculated directly. If the relief of congestion is simulated, too, further wait times arise which are
determined on the basis of the continued simulation without further inflow of traffic until all
queue length reach zero. Any traffic passing through the network in phase 2 thus originates
from the queues determined in phase 1. The maximum transfer flow in each iteration equals
the Mth share of the capacity. M describes the procedure parameter Number of shares for
flow distribution in phase 2 and determines the number of iterations in this phase.
Accordingly, the M-th portion of the interval length of the first simulation phase elapses per
step. After each iteration, the queue lengths on all links are recorded.
We analyze the relief of congestion in the example first and then describe the procedure in
detail.

PTV AG

301

Chapter 5: User model PrT

Illustration 79: Blocking back model, phase 2, relief of congestion. Initial situation

The illustration 79 shows the initial situation prior to relief of congestion in phase 2. Only the
queue lengths from phase 1 are regarded, there is no further influx. For congestion relief, four
portions are used (M = 4).

Illustration 80: Blocking back model, phase 2, relief of congestion. Iterations step 1, route 1

On route 1, the maximum congestion efflux is limited by the link capacity Cap = 100. Thus, Cap
/ M = 25 vehicles can flow off in iteration step 1 (illustration 80).

302

PTV AG

Chapter 5.8: Blocking back model

Illustration 81: Blocking back model, phase 2, relief of congestion. Iteration step 1, route 2

On route 2, the maximum congestion efflux is limited by the capacity of the link in the middle.
Since two routes traverse the link in the middle, only a certain portion of the capacity is
available for route 2 for this iteration, (Cap / M = 100); this portion is (Cap / M) (VolDem(Route
2) / VolDem(link in the middle)) = 100 (200 / 400) = 50 (illustration 81).

Illustration 82: Blocking back model, phase 2, relief of congestion. Iteration step 2, route 1

During iteration step 2, again 25 vehicles flow off via route 1 (illustration 82).

PTV AG

303

Chapter 5: User model PrT

Illustration 83: Blocking back model, phase 2, relief of congestion. Iteration step 2, route 2

Again, 50 vehicles flow off via route 2 (illustration 83).

Illustration 84: Blocking back model, phase 2, relief of congestion. Iteration step 3, route 1

During iteration step 3 only some (12.5) vehicles flow off via route 1 which are part of the
remaining queue on the link in the middle (like in iteration 1 for route 2). The link on the right,
however, is traversed by only one route; that is why the total capacity is provided for the flow
off of the congestion for this iteration (Cap / M = 25) (illustration 84).

304

PTV AG

Chapter 5.8: Blocking back model

Illustration 85: Blocking back model, phase 2, relief of congestion. Iteration step 3, route 2

On the link in the middle, the remaining congestion can flow off via route 2 (illustration 85).
The congestion efflux in phase 2 thus works in a similar way as the formation of the congestion
in phase 1, save that the traffic does not enter the network via the connectors, as usual, but
exists at the links with congestion in the network. In each iteration, we let flow off a portion of
the traffic which is restricted by the capacities of the links and nodes and turns; thus, new
queue lengths will be obtained. This is repeated until either the maximum number of iterations
set for phase 2 is reached (user-defined parameter for the blocking back model) or until the
congestion is no longer available. More accurately, the procedure is described as follows.
Initialize prevQ with queue lengths on links and connectors after phase 1
For j = 1 until (max. number of iterations in Phase 2) or until any prevQ = 0
For each demand segment
For each route R of the demand segment
Calculate the congestion flow off for R according to M and the
capacities
and thus obtain currQ
Calculate wait time
prevQ:= currQ

In detail, the relief of congestion goes like this: In each iteration step, the M-th portion of the
capacity of links, nodes and turns is available. Thus, the maximum traffic that can flow off of
link L due to the link's capacity, is Cap(L) / M per iteration. To each route R, that traverses link
L, a certain share in the capacity is provided; this share equals the route's share in the original
total link volume, i.e. VolDem(R) / VolDem(L). For a link L that belongs to a route R, the
maximum outflow of a congestion results from the following formula:
maxOutflow(L) = (Cap(L) / M) (VolDem(R) / VolDem(L))

Furthermore, the outflow is restricted by the capacity of the To-Node and by the turn capacity.
Let L0, L1, ..., Lk again be the generalized terms for links of a route, i.e. L0 is the origin
connector, Lk is the destination connector, and the real links are in between. Thus, the
maximum outflow from Lj to Lj+1 results as follows:

PTV AG

305

Chapter 5: User model PrT

maxOutflow(Lj, Lj+1) = min{(Cap(Lj) / M) (VolDem(R) / VolDem(Lj)),


(Cap(toNode(Lj)) / M) (VolDem(R) / VolDem(toNode(Lj))),
(Cap(Turn(Lj, Lj+1)) / M) (VolDem(R) / VolDem(Turn(Lj, Lj+1)))}

The traffic flow that actually flows out comes from the existing queues. For each route R, the
traffic originating from the queue on link Lj is as follows:
sourceVolQ(Lj) = prevQ(Lj) (VolDem(R) / VolDem(Lj))

The origin traffic of a link (limited by the maximum outflow maxOutflow) flows to the next link.
This traffic is then added to the origin traffic on the next link. If maxOutflow is smaller than the
origin traffic, queues will form again. The following therefore applies:
Function QueueOutflow(R, M):
arrivedFlow = 0
For j = 0 to k-1
totalSourceVol := sourceVolQ(Sj) + arrivedFlow
propagatingFlow:= min(totalSourceVol, maxOutflow(Lj, Lj+1))
currQ(Lj) := currQ(Lj) - propagatingFlow
arrivedFlow := propagatingFlow
Propagate queue backwards

As in phase 1, the queue is propagated backwards:


Function PropagateQueue2(R):
propagatingQ = 0
For j = k-1 to 1
If currQ(Lj) > K(Lj)
propagatingQ := currQ(Lj) - K(Lj)
currQ(Lj) = K(Lj)
currQ(Lj-1) := currQ(Lj-1) + propagatingQ

Please note that the results of the blocking back model may depend on the order of routes that
are processed. However, the more shares you choose for the distribution of the traffic flow, the
smaller the possible differences will be. If the blocking back model is applied to the same
network for example, on the one hand with an equilibrium assignment and with LUCE on the
other hand, then the results might differ slightly even if all routes are identical.
This is due to the fact, that - in contrast to other assignment procedures - LUCE does not
directly provide routes, but bushes in the first instance, which represent multiple routes at the
same time. In conjunction with LUCE, the blocking back model calculations are performed
directly on the bush level. Since the bushes can include various from-links and to-links for each
link, the traffic flows need to be distributed appropriately. This is performed in a way as if
several routes were processed simultaneously. From this, slightly deviating results may be the
outcome.

Determining the wait times


Resulting from the second simulation stage are the values for the local queue length of each
link after each measuring section (iteration). These values together with the queue length after
the first simulation stage are used to form an integral of the total wait time over the measured
queue length.
The illustration 86 shows an example for the display of the integral indicating the overall wait
time over the interpolated measured queue lengths.

306

PTV AG

Chapter 5.9: Convergence criteria of the assignment quality

Illustration 86: Integral indicating the overall wait time over the interpolated measured queue lengths

This is expressed by the following formula:


Q
QL ( i ) + QL ( i 1 )
W L = I ------L- + ---------------------------------------------------
2M
2

with I being the duration of the first simulation interval in seconds. The sum extends over the
measured values with QL(0) indicating the queue length QL after the first simulation phase. If
the second phase is not calculated, the second term in the bracket is omitted and the wait time
results in the duration of the simulation interval for phase 1 and the queue length at the end of
the first phase.

This results in a mean wait time per vehicle unit as follows

0
if Q ( L ) = 0

=
WL
else
--------------------------------------------- effectivecapacity

On inks with traffic jams, the effective capacity results from the minimum of link capacity
attribute Cap and reduced volume Vol, created through spillback congestion.

5.9

Convergence criteria of the assignment quality


To assess the convergence speed Visum traces the convergence criteria for each iteration, for
all static assignment procedures (apart from incremental assignment). Stochastic assignment
only stores the internal iterations of the previous external iteration (see "Stochastic
assignment" on page 365).
These criteria are output in a list as indicators of the goodness of a PrT assignment (see User
Manual, Chpt. 5.7.1, page 1060). They are initialized prior to each assignment and stored with
the version file.

PTV AG

307

Chapter 5: User model PrT

Among others, the following criteria are calculated:

Hypothetic vehicle impedance

Minimum impedance value calculated hypothetically for the next iteration step on the
assumption that all vehicles based on the current impedances in the network use the
best path.

Gap = (Veh.Imp.- hypothet. Veh. Imp.) / hypothet. Veh. Imp.

Degree of convergence for the network.


The value is the weighted volume difference between the vehicle impedance of the network
of the current iteration and the hypothetical vehicle impedance.

Total Excess Cost TEC (Total Excess Cost)

TEC =

ij r P

min

[ Rr R ij ] q r
ij

where

TEC

Difference between total impedance in the charged network and the hypothetical
impedance resulting if all vehicles took the shortest path per OD pair.

Pij

Number of routes from i to j

Rijmin

minimum impedance among all routes from i to j

Average Excess Cost AEC (Average Excess Cost)

AEC = Excess cost per vehicle


TECAEC = ---------n

The following applies:


n = Number of trips: Total demand in the demand matrix minus the diagonal, thus the sum
of demand contributing to the assignment, no internal traffic.

5.10

Distribution models in the assignment


In Visum, some of the assignment procedures work like this: first, a number of alternatives
(routes or connections) are determined, and then the total demand per OD pair is distributed to
the alternatives. These are the (static) stochastic PrT assignment, the dynamic-stochastic PrT
assignment and the timetable-based PuT assignment. PrT assignment procedures use
alternative routes from origin zone to destination zone, whereas the PuT assignment
procedure provides alternative connections (routes with detailed departure times). For
simplification, we will only mention routes below in this section.
A distribution model determines the share of demand which is assigned to a certain route. This
portion depends on the impedance of a route. In any case, the percentage Pia of route i in
terms of the demand by OD pair in the time interval a is determined by including the impedance
Ria in a distribution function and then calculating the utility Uia of the route. For this distribution
function the Kirchhoff, Logit, Box-Cox, Lohse models and Lohse with variable Beta are
available. The following approach applies to all models:

308

PTV AG

Chapter 5.10: Distribution models in the assignment

1. Impedance Ria is converted to the utility Uia of route i in the time interval a:
Uia = f(Ria)

2. From this utility Uia the percentage of demand Pia is calculated (where n is the total number
of routes).
a

a
P i :=

Ui
----------------------n

j = 1 Uj

The models reveal differences in the functional relation f of impedance and utility.

5.10.1

The Kirchhoff model in the assignment


The utility is as follows:
a

Ui = Ri

The percentage of demand is calculated as follows:


a

a
P i :=

Ri
-----------------
a
Rj
j

The sum of all routes j is taken and is used as a parameter for modeling the impedance
sensitivity. In this distribution method, the ratios of the various impedances are decisive. It
does not matter, therefore, whether two routes have impedances of 5 and 10 minutes, for
example, or 50 and 100 minutes the distribution is the same. The illustration 87 shows the
parameterization of the Kirchhoff distribution model on the interface.

Illustration 87: Parameterization of the Kirchhoff distribution model

5.10.2

The Logit model in the assignment


In this model, the difference, rather than the ratio, between the impedances is used to
calculate distribution. The impedance is additionally divided by a scaling divisor.
The utility is as follows:
a

Ui = e

PTV AG

Ri

309

Chapter 5: User model PrT

The percentage of demand is as follows:


a

a
P i :=

Ri

e
------------------------a

j e

Rj

Parameter describes the sensitivity of passengers towards increased impedances. As in this


case the differences rather than the ratios of the impedances are considered, it does not matter
whether two routes have impedances of 5 and 10 minutes, for example, or 95 and 100 minutes.
The illustration 88 shows the parameterization of the Logit distribution model on the interface.

Illustration 88: Parameterization of the Logit distribution model

5.10.3

The Box-Cox model in the assignment


This distribution model is based on the Box-Cox transformation. For the given 0, the BoxCox transformation is explained as follows.

()

x 1
-------------(x)

log ( x )

if 0
if = 0

When calculating the utility, b()(Ria) is now included in the Logit model instead of Ria, thus
a

Ui = e

()

( Ri )

results.

The percentage Pia of the route i in terms of the demand for time interval a is then calculated
as follows:
a
P i :=

()

( Ri )

e
-------------------------------------a
()

j e

( Rj )

The importance of the Box-Cox model is illustrated by the two special cases below.

310

= 0 (leads to the Kirchhoff distribution)

PTV AG

Chapter 5.10: Distribution models in the assignment

With these parameter settings, b(0)(Ria) = log(Ria) applies, thus the following applies to the
choice:
a

a
Pi

log ( R )

i
Ri
e
- = -----------------= ---------------------------------a

log ( R j )
a
Rj
e

This is precisely the Kirchhoff model.

= 1 (leads to the Logit distribution)


With these parameter settings, b(1)(Ria) = (Ria-1) applies, thus the following applies to the
choice:
a

a
Pi

( Ri 1 )

i
e
e
- = -----------------------= -----------------------------------a
a
( Rj 1 )
Rj
e
e

This is identical to the Logit distribution.


The illustration 89 shows the parameterization of the Box-Cox distribution model on the
interface.

Illustration 89: Parameterization of the Box-Cox distribution model

5.10.4

The Lohse model in the assignment


In this model, the impedances are related to each other in an entirely different way.
R ai

--------- 1
R amin

e
a
P i := ---------------------------------------------applies.
2
a

j e

Rj

--------- 1
R amin

Here, Rmina := minjRja is the smallest occurring impedance, and is again a parameter to
control the impedance sensitivity. When calibrating, do not forget that is squared.

PTV AG

311

Chapter 5: User model PrT

In this case, the impedance of a route is related to the minimum impedance, which therefore
measures the relative difference from the optimum. Due to this different approach, the Lohse
model can be used as an alternative to Kirchhoff and Logit. It should be noted, that the Lohse
distribution formula cannot be regarded as a special form of Box-Cox transformation. The
illustration 90 shows the parameterization of the Lohse distribution model on the interface.

Illustration 90: Parameterization of the Lohse distribution model

5.10.5

Lohse model with variable beta in the assignment


The model is described in Schnabel and Lohse (1997) and differs from the Lohse model in that
the distribution parameter is determined depending on the value of the minimum impedance
Rmina. The calculation can be calibrated in more detail when using three additional parameters
, and .
The following approach applies:

Ui = e

R ai

--------- 1
R amin

The following therefore applies:


R ai

--------- 1
R amin

e
a
P i := ---------------------------------------------2
a

j e

Rj

--------- 1
R amin

is calculated according to the following formula:

= ------------------------------------a

1+e

( R min )

The impedance is additionally divided by a scaling divisor.


The variable distribution parameter improves the modeling of the impedance sensitivity.
Identical ratios of impedances are considered differently for short routes compared to long
routes. In the case of two routes with impedances of 5 and 10 minutes or 50 and 100 minutes,
the distribution is not the same.

312

PTV AG

Chapter 5.10: Distribution models in the assignment

The following example illustrates the effect of the distribution model Lohse with variable beta.
The illustration 91 compares different best paths (10 min, 50 min, 150 min, 300 min) with
"detour" alternatives. The distribution to the routes is done on the basis of the sumptuary ratio
and the absolute value of the best path.
For shorter best paths and their alternatives lower detour sensitivity is assumed than for longer
best paths.

Illustration 91: Distribution with variable beta according to the modified Kirchhoff rule
(please refer to Schnabel / Lohse)

The parameters in illustration 91 are described in table 96.

10

0.800

Rmina
0.010

10 min

3.32

10

0.800

0.010

50 min

4.26

10

0.800

0.010

150 min

6.68

10

0.800

0.010

300 min

9.00

Table 96: Parameters for the distribution with variable beta in illustration 91

The illustration 92 shows the parameterization of the Lohse distribution model with variable
beta on the interface.

PTV AG

313

Chapter 5: User model PrT

Illustration 92: Parameterization of the Lohse distribution model with variable Beta

5.10.6

Comparison of the distribution models for the assignment


The effects of the four distribution models (Kirchhoff, Logit, Box-Cox and Lohse) are illustrated
in a simple example. The table 97 to table 99 show three simple cases of a choice between two
alternatives which represent either routes or connections. The model parameters used can be
found in table 100.

Example 1
Alternative 1 has an impedance of 5, alternative 2 an impedance of 10. Thus alternative 2
has a 5-unit higher impedance or a double impedance compared to alternative 1.

Example 2
The impedance of example 1 is increased by 100 units, so that alternative 1 now has an
impedance of 105 and alternative 2 an impedance of 110. This means that alternative 2
thus has a 5-unit higher impedance, as in example 1; however, the impedance ratio is now
0.95 rather than 0.5.

Example 3
The impedance of example 1 is doubled, so that alternative 1 now has an impedance of 50
and alternative 2 an impedance of 100. This now means that alternative 2 has a 50-unit
higher impedance; the impedance ratio is 0.5 as in example 1.

The distribution results demonstrate that in the Logit model the difference of impedances is
decisive, so that examples 1 and 2 result in the same distribution values. The Kirchhoff model,
on the other hand, evaluates the ratio of the impedances and thus generates the same
distribution values for examples 1 and 3. The Box-Cox model allows a combination of Logit
and Kirchhoff, which is also illustrated by the distribution values.
It would seem that the Logit model cannot be recommended for practical use, because the
basis for a passengers choice is different for short and long connections. In practice, it will
certainly make a difference whether a passenger has to travel 5 and 10 minutes (table 97), or
105 and 110 minutes (table 98). In the case of long journeys, the additional 5 minutes are not
as important as in case of short trips. The weaknesses of the Kirchhoff model in the example
in table 99, where one can expect all passengers to chose alternative 1, are not relevant for the
assignment, because connections that differ to such an extent would not be found in the search
at all and would therefore not be real alternatives for the road-user.

314

PTV AG

Chapter 5.11: Incremental assignment

No.

Kirchhoff

Logit

Box-Cox

Lohse

94 %

78 %

86 %

100 %

10

6%

22 %

14 %

0%

Table 97: Distribution for two alternatives with impedance 5 and 10


No.

Kirchhoff

Logit

Box-Cox

Lohse

105

55 %

78 %

62 %

51 %

110

45 %

22 %

38 %

49 %

Table 98: Distribution for two alternatives with impedance 105 and 110
No.

Kirchhoff

Logit

Box-Cox

Lohse

50

94 %

100 %

100 %

100 %

100

6%

0%

0%

0%

Table 99: Distribution for two alternatives with impedance 50 and 100
Kirchhoff

=4

Logit

= 0.25

Box-Cox

= 1, = 0.5

Lohse

=4

Table 100: Model parameters

5.11

Incremental assignment
The incremental assignment procedure models how a network continuously fills up. At the
beginning, road users can use a free network for which exactly one shortest route exists for
every origin/destination relation. The traffic network is then successively loaded. Every step
congests the road network with additional vehicles and, in this way, increases impedance on
the congested links, turns and connectors. Because of the changed impedance, alternative
shortest routes may be found in every step.
The matrix is incrementally assigned to the network in the form of several parts. In this process,
the entire demand is proportionally distributed over the number of iteration steps defined by the
user (maximum 12). The default is an incremental assignment with three iteration steps (33 %,
33 % and 34 %).

PTV AG

The first step determines lowest impedance routes for all required OD-relations of the
current network for either a free network or based on a basic volume.
The defined percentage of the first incremental step of the matrix is then assigned to these
routes.
Subsequently, the new network impedances resulting from these volumes are calculated
via the VD functions.
On this basis, the next iteration step again calculates lowest impedance routes.

315

Chapter 5: User model PrT

This procedure is continued until the entire matrix has been assigned to the network.

If 100% is entered for the first iteration step, Visum calculates the impedances of the current
network and carries out a so-called best-route assignment.

5.11.1

Example of the incremental assignment


The table 101 shows how the incremental procedure works on the example network (see
"Example network for the PrT assignment procedures" on page 213). The 2,000 car trips are
assigned in three iteration steps (50 %, 25 %, 25 %).

Iteration step 1
The shortest route, in the unloaded network, is route 2 with an impedance of 18:00 min. It
is loaded with 50 % of the car trips, i.e. 1,000 car trips.

Iteration step 2
The shortest route in the unloaded network is route 1 with an impedance of 20:50 min. It is
loaded with 25 % of car trips, that is, with 500 car trips.

Iteration step 3
After the second iteration step, route 1 remains the shortest route with an impedance of
29:50 min. It is again loaded with 25 % of the car trips, i.e. with another 500 car trips. It now
has a total of 1,000 car trips.

After the third iteration step, route 3 turns out to have the lowest impedance.
This route, however, is no longer found because all trips have been assigned.

In the example above, the impedance of a route results from the sum of the link impedances of
the route. Additional impedances for connectors and turns are not considered. In addition to
this, it is assumed that impedance results from current travel time tCur, and that current travel
time in turn results from the BPR function with a=1, b=2 and c=1.
LinkNo

316

Type

Length [m]

v0 [km/h]

Capacity

t0 [min]

20

5,000

100

1,200

03:00

20

5,000

100

1,200

03:00

20

5,000

100

1,200

03:00

20

5,000

100

1,200

03:00

20

5,000

100

1,200

03:00

20

5,000

100

1,200

03:00

30

16,000

80

800

12:00

30

5,000

80

800

03:45

10

40

10,000

60

500

10:00

11

40

5,000

60

500

05:00

PTV AG

Chapter 5.11: Incremental assignment

Route

Links of the route

Length [m]

t0 [min]

1+8+9

26,000

18:45

1+2+3+5+6+7

30,000

18:00

10+11+5+6+7

30,000

24:00

LinkNo

Volume

tCur

Step 1 (50%)

Volume

tCur

Step 2 (25%)

Volume

tCur

Step 3 (25%)

1,000

05:05

1,500

07:41

2,000

11:20

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

1,000

05:05

12:00

500

16:41

1,000

30:45

03:45

500

05:13

1,000

09:37

10

10:00

10.00

10.00

11

05:00

05:00

5:00 AM

Route

Volume

tCur

Step 1 (50%)

Volume

tCur

Step 2 (25%)

Volume

tCur

Step 3 (25%)

20:50

500

29:35

1,000

51:42

1,000

30:30

1,000

33:06

1,000

36:45

30:15

30:15

30:15

Table 101: Example of the incremental assignment (BPR function a=1, b=2, R=tCur)

5.11.2

Procedure of the incremental assignment


The illustration 93 shows the procedure of an incremental assignment.

PTV AG

317

Chapter 5: User model PrT

Input

Demand matrix F
Number of iteration steps N
Demand proportion Pn for each iteration step n = 1, N

n=0
Volume q 0 = 0 or basic volume

Impedance
determination

Determination of impedance R n of all network objects with


the corresponding impedance function.

Route search

Determination of the best route for all relations based on


impedance Rn.

Volume

Assignment of travel demand which results from Pn onto


network objects which are part of the best route.
q n+1 = qn + Pn F

n = n +1
no
Query

n= N ?
yes

End

Determination of impedance Rn of all network objects with


the corresponding impedance function.
Illustration 93: Procedure of the incremental assignment

5.11.3

Input and output attributes of the incremental assignment


To execute the incremental assignment, certain entries have to be made. After calculation, the
results are available in the output attributes and can be displayed in the list view (see User
Manual, Chpt. 12.1, page 1369) or in the network editor (see User Manual, Chpt. 12.2,
page 1400). The table 102 gives an overview of which input attributes have to be maintained.
The table 103 lists the output attributes which store the results of the procedure.

318

PTV AG

Chapter 5.11: Incremental assignment

Table 102: Input attributes for the incremental assignment

The abbreviations represent the following:

PTV AG

x1

The toll by PrTSys has to be inserted manually in the impedance function

(X)

Can be used optionally

(*)

Apart from the parameters which are directly set in the assignment procedure

319

Chapter 5: User model PrT

Table 103: Output attributes of the incremental assignment

5.11.4

Evaluation of the incremental assignment


Lohse (1997) lists the following decisive disadvantages of the incremental assignment
procedure.

5.12

The number and the size of layers (partial matrices) mainly decide on the goodness of the
results. However, there is no procedure to specify optimal layers.
The calculation ends after the specified number of steps has been executed without
checking correspondence between the resulting traffic volume and link impedances.

Equilibrium assignment
The Equilibrium assignment distributes the demand according to Wardrop's first principle.
"Every road user selects his route in such a way, that the impedance on all alternative routes
is the same, and that switching to a different route would increase personal travel time (user
optimum)."
This behavioral hypothesis underlies the unrealistic assumption that every road user is fully
informed about the network state. In transport planning this hypothesis is approved of given a
fundamental methodical advantage of the equilibrium assignment - with quite general

320

PTV AG

Chapter 5.12: Equilibrium assignment

requirements, the existence and uniqueness of the assignment result (expressed in volumes
of the network object) is guaranteed. Moreover, measures for the distance of an approximation
solution from the equilibrium exist, from which an objective termination criterion can be derived
for the procedure, which generally is an iterative problem solution.
The equilibrium assignment determines a user optimum which differs from a system optimum,
as shown in table 104 and table 105.

A user optimum means that the same impedance results for all routes of a traffic relation
between zones i and j (within the scope of calculation accuracy). This results directly from
the condition, that changing to another route is not profitable for any road user (table 104).
A system optimum however means that the total impedance in the network, which is the
product of route impedance and route volume is minimized for all OD pairs. On average,
this procedure leads to shorter journey times per road user, but there are (few) road users
which use routes to serve the general public, with an impedance above average
(table 105).

Route

Links

Volume

tCur [min]

Volume tCur

1+8+9

736

38:19

470:05:53

1+2+3+5+6+7

995

38:21

636:01:21

10+11+5+6+7

269

38:20

171:50:02

Total

2,000

1277:57:17

Table 104: Calculation of the user optimum for the example network
Route

Links

Volume

tCur [min]

Volume tCur

1+8+9

734

37:43

461:46:27

1+2+3+5+6+7

919

37:13

569:58:45

10+11+5+6+7

347

41:13

238:11:24

Total

2,000

1269:56:36

Table 105: Calculation of the system optimum for the example network

5.12.1

Evaluation of the equilibrium assignment

PTV AG

Because the procedure only terminates when all routes of any OD pair are in the balanced
state, the procedure provides more realistic results than the incremental procedure.
For a lower volume/capacity ratio, a similar result is achieved as with best-route
assignment, because the route search does not find new routes. In this case it is
recommended to use an incremental assignment with suitable parameters as initial solution
or the Equilibrium_Lohse procedure.
The computation time required by the equilibrium assignment depends on the volume/
capacity ratio in the network. Because new routes are found in every iteration step for a
strongly saturated network, more computation time is required in this case.
Compared to stochastic assignment procedures (see "Stochastic assignment" on page 365
and "Dynamic stochastic assignment" on page 419) the equilibrium assignment provides
distinct network volumes. Compared to the number of calculated iterations, the gap is a
more objective termination criterion.

321

Chapter 5: User model PrT

5.12.2

Introductive example for the equilibrium assignment


The effectiveness of the equilibrium assignment is described as follows on the basis of the
example described in table 106 and illustration 94. The example analyzes the relation between
traffic zone "village A" and traffic zone "city X".
The total impedance of a route, to keep it simple, results from the sum of link impedances of
the route (see "Impact models" on page 205). Impedances for connectors and turns are not
considered in the route search. In detail, the following assumptions apply:

The impedance of the links is determined from the current travel time tCur. The current
travel time tCur is in turn calculated using the capacity restraint function BPR with a=1, b=2
and c=1.
The access and egress times for the connectors are not considered, that is, they are set to
0 minutes.
Turn penalties are not considered.

With regard to the traffic demand the following applies.

The traffic demand between A-Village and X-City is 2,000 car trips during peak hour.
Capacity and demand refer to one hour.

The example network contains three routes which connect village A and city X.

Route 1 via nodes 10 11 41 40


Route 2 via nodes 10 11 20 21 30 31 40
Route 3 via nodes 10 12 21 30 31 40

Route 1 mainly uses country roads and is 26 km long. It is the shortest route. Route 2 is 30 km
long. It is the fastest route because the federal road can be traversed at a speed of 100 km/h
if there is free traffic flow.
Route 3 which is also 30 km long is an alternative route which only makes sense if the federal
road is congested.

322

PTV AG

Chapter 5.12: Equilibrium assignment

village A
1

10

10

11

12

11

41

20

40

21

30

city X

31

Illustration 94: Example network for the equilibrium assignment


LinkNo From Node To Node
11

Type

Length [m]

Capacity [car units/h]

v0-PrT [km/h]

10

20 Federal road

5,000

1,200

100

11

20

20

20 Federal road

5,000

1,200

100

21

20 Federal road

5,000

1,200

100

20

40

90 Rail track

10,000

21

30

20 Federal road

5,000

1,200

100

30

31

20 Federal road

5,000

1,200

100

31

40

20 Federal road

5,000

1,200

100

11

41

30 Country road

16,000

800

80

40

41

30 Country road

5,000

800

80

10

10

12

40 Other roads

10,000

500

60

11

12

21

40 Other roads

5,000

500

60

Table 106: Example network for the equilibrium assignment

As a result, the assignment provides values from table 107 for the three routes (PrT paths).
Route

tCur

Impedance

Volume(AP)

46min 39s

2,798

1,157.488

46min 34s

2,794

618.079

46min 12s

2,772

224.432

Table 107: Assignment results for the three PrT paths

PTV AG

323

Chapter 5: User model PrT

The most important assignment results for the links are displayed in table 108.
Link tCur

Impedance Volume(AP) Saturation PrT (AP) VehicleHr(tCur) VehKmTravelled


PrT

11min
40s

700

1,908

170 370h 54min 19s

9,537.839

5min 47s

347

1,157

96 111h 43min 15s

5,787.442

5min 47s

347

1,157

96 111h 43min 15s

5,787.442

7min 48s

468

1,450

126 188h 29min 38s

7,249.603

7min 48s

468

1,450

126 188h 29min 38s

7,249.603

7min 48s

468

1,450

126 188h 29min 38s

7,249.603

26min
35s

1,595

750

110 332h 23min 38s

12,001.270

8min 19s

499

750

110 103h 52min 23s

3,750.397

10

15min
12s

912

292

72

74h 3min 56s

2,924.321

11

7min 36s

456

292

72

37h 1min 58s

1,462.161

Table 108: Assignment result at the links

5.12.3

Input and output attributes of the equilibrium assignment


To execute the equilibrium assignment, certain entries have to be made. After calculation, the
results are available in the output attributes and can be displayed in the list view (see User
Manual, Chpt. 12.1, page 1369) or in the network editor (see User Manual, Chpt. 12.2,
page 1400). The table 109 gives an overview of which input attributes have to be maintained.
The table 110 lists the output attributes which store the results of the procedure.

324

PTV AG

Chapter 5.12: Equilibrium assignment

Table 109: Input attributes of the equilibrium assignment

The abbreviations represent the following:

PTV AG

x1

Toll PrTSys has to be inserted manually in the impedance function

Generally possible, however not recommended

(*)

Apart from the parameters which are directly set in the assignment procedure

325

Chapter 5: User model PrT

Table 110: Output attributes of the equilibrium assignment

If you use metric units, enter the long lengths for kilometers and speeds in km/h. For imperial
units enter the long lengths in miles and speeds in mph.

5.12.4

Procedure of the equilibrium assignment


The equilibrium state calculation can be formulated as an optimization problem with a convex
objective function and linear secondary conditions.
qa

min!

aE

Ra ( x ) dx
0

q ijr > 0, ijr

r qijr = qij, ij
ijr : a P
a E

q ijr = q a, a
ijr

qa

aE

qa =

i qiu j quj = Du Ou, u

The following applies:

326

E
qa

the set of all edges in a network and a one of these edges

Ra(x)

the impedance of object a with volume x (monotonically increasing in x)

qij

the total demand (number of trips) from zone i to zone j

qijr

volume of route r from zone i to zone j

Pijr

route r from zone i to zone j

E+u

the set of the incoming edges at node u

volume of object a

PTV AG

Chapter 5.12: Equilibrium assignment

E-u

the set of the outgoing edges at node u

Du

destination traffic at node u

Ou

origin traffic at node u

In Visum, edges are all links, turns and connectors, whereas nodes are zones and network
nodes.
The objective function shows that the sum of impedances of all edges is minimized. The
secondary conditions indicate the following (from top to bottom).

All path volumes have to be positive.


The volumes of all paths from zone i to j have to add up from the total demand from i to j.
The volume of an edge results from the sum of volumes of all paths, which contain this
edge.
Flow conservation applies at each node. When a node corresponds with a zone, the
difference between the volumes of all incoming edges and the volumes of all outgoing
edges have to correspond exactly with the difference between the destination and origin
traffic. There is no origin and destination traffic at network nodes, thus the difference must
be zero.

Due to the non-linear objective function, the optimization problem is not solved directly but
iteratively. Because of the monotonicity of the impedance function, the minimum is reached, so
that starting with a starting solution between the alternative paths, a movement i-j is shifted, so
that the paths all have the same impedance.
During the equilibrium assignment the steps showed in illustration 95 will be made.

PTV AG

327

Chapter 5: User model PrT

Input

Loaded network (starting solution) with loaded routes r


Maximum number of iteration steps N
Maximum absolute deviation of impedance E abs
Maximum relative deviation of impedance E rel

n =0

Network
balancing

Balance the volumes of all routes r for all OD pairs ij so


that the impedance R rij of the routes is:
| min. Rij max. Rij |< Eabs or
max. Rij / min. Rij < 1 + Erel

n = n +1

Route search

Query

Determination of the best routes for all relations i-j based


on impedance R(n) .

New routes found and


n < N and
relative gap > max. permitted relative gap?

yes

no
End
Illustration 95: Procedure of the equilibrium assignment

Based on an assignment result from a previously calculated assignment or an incremental


assignment (by default) as a starting solution, the state of balance is reached by multiple step
iteration. In the inner iteration step, two routes of a relation are brought into a state of
equilibrium by shifting vehicles. These iteration steps are carried out for all relations until all
relations are in a state of balance. Every shift of vehicles from one route to another has an
immediate effect on the impedances of the traversed network objects.
The outer iteration step checks if new routes with lower impedance can be found as a result of
the current network state. If this is the case for at least one relation, another state of balance
must be calculated.
The following termination condition applies. A state of balance has been reached if the inner
iteration step did not need to shift vehicles, and no new routes were later found by the external
iteration step.
Also the convergence criterion Gap can be used as termination condition.

328

PTV AG

Chapter 5.12: Equilibrium assignment

Network balancing
The procedure of the network balancing is displayed in illustration 96.

Input

Route search

Pair balancing

Update
impedance

Query

Volume q r of each route r,


Impedance Rr of each route r,
Maximum absolute deviation of impedance Eabs
Maximum relative deviation of impedance Er el

Select two routes:


Route r1: Route with minimal impedance R1
Route r2: Route with maximum impedance R2

Balance the volume of routes r1 and r 2 in such a way that


the impedance of the routes is:
| R1 R2 |< Eabs or
1 Er el < R1 / R2 < 1 + Er el
If the volume of route r 1 or r2 is 0 after balancing, delete
route.

Update impedance of all network objects whose volume


has changed.

Is the following condition fulfilled for the route with the


minimum impedance R1, and the route with the maximum
impedance R2?
| R1 R2 | < Eabs or
R2 / R1 < 1 + Er el

no

yes
End

Network balancing completed

Illustration 96: Procedure of the network balancing for an OD pair in the equilibrium assignment

Termination criterion
Visum cancels the iteration process for calculating the equilibrium, if one of the following
conditions has been fulfilled:

PTV AG

Network balancing has been achieved, this means a permitted deviation of impedances of
the routes compared in pairs was reached or undercut.
The specified number of external iterations was reached without a network balancing being
reached (in very highly loaded networks it is possible that the permitted deviations which
were specified do not result in a state of balance because only integer vehicles are shifted).
The convergence criterion Max. gap is reached or undercut.

329

Chapter 5: User model PrT

5.12.5

In case of an equilibrium assignment with blocking back model the maximum deviation was
reached or undercut (see "Blocking back model" on page 292). The procedure is cancelled
if the congestion volume values and the congestion wait times of two external iterations
deviate by the max. rel. difference or less.

Calculation example for the equilibrium assignment


Route

Volume

tCur [min]

Starting solution

1,000

51:42

Routes 1 + 2 are known

1,000

36:45

30:15

Network balancing 0

776

41:54

Routes 1 + 2

1,224

41:56

33:22

Iteration step 1: route search finds route 3


Network balancing 1

649

36:25

Routes 1 + 3

1,224

42:58

127

36:23

Max. imp. route = 2, Min. imp. route = 3


Network balancing 2

649

35:15

Routes 2 + 3

1,067

40:17

284

40:15

Max. imp. route = 2, Min. imp. route = 3


Network balancing 3

734

38:09

Routes 1 + 2

982

38:10

277

38:51

Max. imp. route = 3, Min. imp. route = 1


Network balancing 4

741

38:27

Routes 1 + 3

982

38:07

277

38:31

Max. imp. route = 3, Min. imp. route = 2


Network balancing 5

741

38:30

Routes 2 + 3

990

38:14

269

38:15

Max. imp. route = 1, Min. imp. route = 2


Network balancing 6

736

38:19

Routes 1 + 2

995

38:21

269

38:20

Table 111: Example equilibrium procedure (BPR function a=1, b=2)

330

PTV AG

Chapter 5.13: Linear User Cost Equilibrium (LUCE)

The table 111 shows how the equilibrium procedure works on the example network (see
"Example network for the PrT assignment procedures" on page 213). The volume determined
with the incremental procedure is used here as the initial solution (see "Example of the
incremental assignment" on page 316). This starting solution encompasses two routes, each
loaded with 1,000 car trips. The specified absolute deviation is a value of five impedance units,
and the relative deviation is specified as being 0.1 %. Based on the starting solution, the
following steps are then carried out.

Network balancing for starting solution


The volumes of the routes 1 and 2 are changed in such way that the deviation of the two
route impedances is below the specified deviation. With a volume of 776 respectively 1,224
vehicles for routes 1 and route 2, this is guaranteed.

Route search for iteration step 1


After network balancing of routes 1 and 2, the shortest path search of the first iteration step
determines route 3.

Network balancing for iteration step 1


The three routes are balanced in pairs until the impedance of all routes accords with the
specified deviation.
This is the case in the example if one of both conditions applies:

The absolute deviation between maximum and minimum impedance is smaller than 5
seconds.
The relative deviation between the maximum and minimum impedance is less than
0.1 %.
Network balancing by pairs always changes the volumes of the route with the minimum
impedance and the route with the maximum impedance.
Route search for iteration step 2
No new route is found, the equilibrium procedure terminates.

5.13

Linear User Cost Equilibrium (LUCE)


Similarly to origin-based methods, the problem is partitioned by destinations in the LUCE
procedure. The main idea is to seek at each node a user equilibrium for the local route choice
of drivers directed toward the destination among the arcs of its forward star.. The travel
alternatives that make up the local choice sets are the arcs that belong to the current bush. A
bush is an acyclic sub-graph that connects each origin to the destination at hand. The cost
functions associated to these alternatives express the average impendence to reach the
destination linearized at the current flow pattern.
The unique solutions to such local linear equilibria in terms of destination flows, recursively
applied for each node of the bush in topological order, provide a descent direction with respect
to the classical sum-integral objective function. The network loading is then performed through
such splitting rates, thus avoiding explicit path enumeration.

PTV AG

331

Chapter 5: User model PrT

5.13.1

Mathematical formulation and theoretical framework


The transport network is represented through a directed graph G = (N, A), where N is the set of
the nodes and A NN is the set of the arcs. In the graph, the nodes represent the zone
centroids and the road intersections (Visum network nodes), while the arcs represent the links
and the connectors. When turns with impendence or restrictions are introduced in the network
model, then the node is properly exploded, so that such turns are associated to specific or no
arcs of the graph.
We adopt the following notation:
fij

Total flow on arc ijA, generic element of the (|A|1) vector f

cij

Cost of arc ijA, generic element of the (|A|1) vector c

cij(fij)

Cost function of arc ijA

ZN
Dod

Set of the zone centroids

Kid

Set of the acyclic paths between node iN and destination dZ

K = oZ dZ Kod is the set of paths available to road users

ij

Demand flow between origin oZ and destination dZ, generic element of the (|Z|21) vector
D, that is the demand matrix in row major order

ijk = 1, if arc ijA belongs to path k, and 0, otherwise for kK, this is the generic element
of the (|A||K|) matrix D

odk

odk is 1, if path kK connects origin oZ to destination dZ (i.e. kKod), and 0, otherwise


this is the generic element of the (|Z|2|K|) matrix L

Fk

Flow on path kK, generic element of the (|K|1) vector F

Ck

The cost of path k for kK this is the generic element of the (|K|1) vector C

Wid

Minimum cost to reach destination dZ from node iN

Set of real numbers

|S|

Cardinality of the generic set S

There are two fundamental relations between flow variables. The flow on arc ijA is the sum
of the flows on the paths that include it:
fij = kK ijk Fk

The travel demand between origin oZ and destination dZ must be equal to the sum of the
flows on the paths that connect them:
kKod Fk = Dod

Moreover, all path flows must satisfy non-negativity constraints.


As usual, we assume additive path costs, i.e. the impendence Ck associated by users to a
given path k is the sum of the costs on the arcs that belong to it:
Ck = ijA ijk cij

(6)

By definition, the minimum cost to reach destination dZ from node iN is the cost of any
shortest path that connects them:

332

PTV AG

Chapter 5.13: Linear User Cost Equilibrium (LUCE)

Wid = min{Ck : kKid}

(7)

In this case, the traffic assignment problem can be formalized through the following program:

min (f) =

c
(
x
)
d
x
:
f

ij A ij

f ij

(8)

where

{f|A|: f = F, F} is the set of feasible arc flows

{F|K|: F 0, F = D} is the set of feasible path flows

To ensure the existence and uniqueness of the solution to problem (8) we assume that:
cij(fij) is non-negative, continuous, strictly monotone increasing;
Kod is non-empty;
Dod is non-negative.

Problem (8), which is convex, can also be expressed in terms of path flows as follows:

k K ij Fk

min (F) =
c
(
x
)
d
x
:
F

(9)

ij

ij

f=0

where, although the solution uniqueness does not hold anymore, the convexity of the
mathematical program is preserved, implying that any descent algorithm in the space of path
flows will provide one of the global solutions, which then make up a convex set.
k

The relevance of program (9) to traffic assignment stands from the fact that, in the case of
additive path costs, its first order (necessary) conditions coincide with the following formulation
of the deterministic user equilibrium based on Wardrop's Principles, for each oZ and dZ:
kKod

(10.1)

Ck Wo ,

kKod

(10.2)

Fk 0,

kKod

(10.3)

Fk (Ck - Wod) = 0,
d

kKod Fk = Dod

(10.4)

Based on (10.1) to (10.4)

all used paths (Fk > 0) have minimum cost (Ck = Wod);

any unused path (Fk = 0) has not a lower cost (Ck Wod).

We have a user equilibrium if conditions (10.1) to (10.4) hold jointly for each OD couple, while
considering that each path cost Ck is a function (potentially) of all the path flows F through the
arc cost function:
Ck = ijA ijk cij(kK ijk Fk), in compact form C = T c(F)

(11)

Since the gradient of (F) C = T c(F), by linearizing the objective function of problem (9) at
a given a point F, for X F we obtain:

PTV AG

333

Chapter 5: User model PrT

(X) = (F) + CT(X-F) + o(||X-F||).

(12)

From equation (12) we recognize that a direction E-F is descent if and only if:
CT(E-F) < 0.

(13)

In other words, to decrease the objective function and maintain feasibility we necessarily have
to shift path flows getting a lower total cost with respect to the current cost pattern, i. e. move
the current solution from F towards an E such that CTE < CTF, where C = Tc(F). The
necessity derives from the convexity of the problem, since in this case at any point X such that
CT(X-F) > 0 we have: (X) > (F).
This approach to determine a descent direction can be applied to each OD pair separately, to
each destination, or to the whole network jointly. Based on the above general rule, setting the
flow pattern E by means of an all-or-nothing assignment to shortest paths clearly provides a
descent direction. If we adopt such a direction for all OD pairs of the network jointly, and apply
along it a line search, we obtain the well known Frank-Wolfe algorithm. However, at equilibrium
each OD pair typically uses several paths, implying that any descent direction that loads a
single path is intrinsically myopic; in fact such algorithms tail badly.
Once we get a feasible descent direction E-F, since is convex, we can move the current
solution along the segment F+(E-F) and take a step (0,1] such that the objective function
of problem (9), redefined as () = (F+(E-F)), is sufficiently lowered. In this respect,
knowing that is C1 and convex, and thus also is such, several methods are available to
determine an which minimizes (). Visum uses an Armijo-like search and determines the
largest step = 0.5k, for any non-negative integer k, such that
(0.5k)/ < 0.

(14)

This method requires to compute the directional derivative of the objective function:
()/ = [c((F+(E-F)))]T[(E-F)],

(15)

which implies to evaluate the arc costs at the candidate flows F+(E-F) and then the
difference between the corresponding total costs obtained with the flows E and F. If such total
costs with E are smaller than those with F, then ()/ is negative so that the optimal solution
is more toward E, and vice versa.

5.13.2

Local user equilibrium


In this section we present a new method to determine a descent direction, which is based on
local shifts of flows that satisfy the total cost lowering rule and exploits the inexpensive
information provided by the derivatives of the arc costs with respect to arc flows.
To grasp immediately the underlying idea, we can refer to the simplest network where one OD
pair with demand D is connected by two arcs with cost function c1(f1) and c2(f2), respectively.
At the current flow pattern f = (D/2, D/2) it is c1 < c2 (see illustration 97), so that an all or nothing
approach would lead to a descent direction (D, 0), which is far away from the equilibrium f*
(gray circle in the Figure). The LUCE approach, instead, is to consider the first order
approximations of the cost functions at the current flow pattern, i.e. ca + ca(fa)/fa (fa - fa), and
determine a user equilibrium e among these lines (white circle in the Figure): this descent
direction efficiently approaches the equilibrium f*. In most cases =1 can be taken as the new
iterate with a step one.

334

PTV AG

Chapter 5.13: Linear User Cost Equilibrium (LUCE)

Illustration 97: Linear User Cost Equilibrium between two paths

To reach any destination dZ, at the equilibrium only shortest paths are utilized. Given that the
arc cost functions are strictly monotone increasing, they make up an acyclic [*1] sub-graph of
G, i.e. a (reverse) bush rooted at d. At strict monotonicity, any arc cost can be null only if its flow
is such. However, in Visum links and connectors may have null impedance, producing twofold
consequences: a) the corresponding arc cost functions loose strict monotonicity, so that
uniqueness is not guaranteed anymore. b) The sub-graph made-up by arcs with positive
destination flows at some of the possible equilibria may be cyclic. The implementation of LUCE
in Visum specifically addresses this issue and converges to one among the possible equilibria
by forcing an acyclic solution and equally splitting the flow among all alternatives with minimum
cost in presence of uncongested sub-paths. This special case is not further dealt with below.
On this base, when seeking a descent direction, in the following we will limit our attention to the
current bush B(d) and introduce an updating mechanism to make sure that eventually any
shortest path will be included into it; equilibrium is actually only attained this way. Let us focus
on the local route choice at a generic node iN for road users directed to destination dZ.
For the topology of the bush we will use the following notation:
FSB(i, d) = {jN: ijB(d)} the forward star of node iN made-up by nodes that can be
reached from it through arcs belonging to the current bush B(d) of
destination dZ
BSB(i, d) = {jN: ijB(d)} the backward star of node iN made-up by nodes that can reach it
through arcs belonging to the current bush B(d) of destination dZ

For the flow pattern we will use the following notation:


fijd

current flow on arc ijA directed to destination dZ


By construction it is fijd = 0 for each jFSB(i, d);
moreover it clearly is: fij = dZ fijd

fid = jFSB(i, d) fijd

current flow leaving node iN to destination dZ

yijd

yijd = fijd / fid current flow proportion on arc ijA directed to destination dZ, if
fid > 0, yijd = 0 else

eijd

PTV AG

descent direction, in terms of flow on arc ijA directed to destination dZ

335

Chapter 5: User model PrT

eid

descent direction, in terms of flow leaving node iN directed to destination dZ

eijd = eijd / eid

descent direction, in terms of flow proportion on arc ijA directed to destination


d Z

For the cost pattern we will use the following notation:


Cid

average cost to reach destination dZ from node iN

gij

Cost derivative of arc ijA

Gid

Derivative of the average cost to reach destination dZ from node iN

The average cost Cid is the expected impendence that a user encounters by travelling from
node iN to destination dN. Here it is defined recursively based on the current flow pattern:
if fid > 0, then Cid = jFSB(i, d) yijd (cij + Cjd), else

(16.1)

Cid = min{cij + Cjd: jFSB(i, d)},

(16.2)

as if drivers utilize paths accordingly with the current flow proportions. In the following we
assume that the cost function cij(fij) is continuously differentiable for each arc ijA:
gij = cij(fij) / fij

(17)

Under the assumption that an infinitesimal increment of flow leaving node iN directed towards
destination dZ would diverge accordingly with the current flow proportions, we have:
if fid > 0, then Gid = Cid / fid = jFSB(i, d) yijd 2 (gij + Gjd), else

Gid

jFSB(i, d) [Cid

= cij +

Cjd]

(gij +

Gjd)

jFSB(i, d) [Cid

= cij +

(18.1)
Cjd],

(18.2)

where the derivatives gij + Gjd are scaled by the shareyijd of fid utilizing arc ij and then passing
through node j, that jointly with the flow proportion involved in the averaging yields the square
yijd 2.
The average costs and their derivatives can be computed by processing the nodes of the bush
in reverse topological order according to d, starting fromCdd = Gdd = 0.
We now address the local user equilibrium for the eid drivers directed to destination dZ, whose
available alternatives are the arcs of the bush exiting from node iN. To each travel alternative
we associate the cost function:
vijd(eijd) = (cij + Cjd) + (gij + Gjd) (eijd - yijd eid),

(19)

resulting from a linearization at the current flow pattern of the average cost encountered by a
user choosing the generic arc ij, with jFSB(i, d).
This problem can be formulated, in analogy to (10.1) to (10.4), by the following system of
inequalities:
eijd [vijd(eijd) - Vid] = 0,

jFSB(i, d),

(20.1)

vijd(eijd) Vid,

jFSB(i, d),

(20.2)

eijd 0,

336

jFSB(i, d),

(20.3)

PTV AG

Chapter 5.13: Linear User Cost Equilibrium (LUCE)

jFSB(i, d) eijd = eid,

(20.4)

where we denote:
Vid

local equilibrium cost to reach destination dZ from node iN;

vijd

Cost of the local alternative jFSB(i, d), to reach destination dZ from node iN via j.

If eid = 0, the solution to the above problem is trivially: eijd = 0, for each jFSB(i, d). Consider
then the case where eid > 0. To improve readability, problem (20.1) to (20.4) can be rewritten
as:
xj (aj + bj xj - v) = 0,

jJ,

(21.1)

aj + bj xj v,

jJ,

(21.2)

xj 0,

jJ,

j xj = 1,

(21.3)
(21.4)

where:
J
aj

{(i, j, d): jFSB(i, d)}

bj

(gij + Gjd) eid

xj

eijd / eid

Vid

(cij + Cjd) - (gij + Gjd) eid yijd

Applying the usual Beckmann approach we can reformulate the equilibrium problem (21.1) to
(21.4) as the following quadratic program:
min{jJ 0 xj(aj + bj x) dx: xX} = min{jJ aj xj + 0.5 bj xj2: xX},

(22)

where X is the convex set of all vectors satisfying the feasibility conditions (21.3) and (21.4).
The gradient of the objective function is a vector with generic entry aj + bj xj, and then the
Hessian of the objective function is a diagonal matrix with generic entry bj. Therefore, if all
entries bj are strictly positive, the Hessian is positive definite and problem (22) has a unique
solution. In order to ensure such a desirable property we assume without loss of generality that
the derivates gij are strictly positive for all arcs ijA. Since the arc cost functions are strictly
monotone increasing, gij can be zero only if also fijd is zero. Therefore, at the equilibrium bj = 0
implies xj = 0. In practice we will substitute any gij = 0 with a small .
To solve problem (21.1) to (21.4) we propose the following simple method. In order to satisfy
condition (21.1), either it is xj = 0, and in this case condition (21.2) requires aj v, or it is aj + bj
xj = v. Let J0 J be the set of alternatives with zero flow, that is J0 = {jJ: xj = 0}. For any given
J0 the solution is immediate, since from (21.4) it is jJ (v - aj) / bj = 1; therefore we have:
v = (1 + jJ\J0 aj / bj) / (jJ\J0 1 / bj),

PTV AG

(23.1)

xj = (v - aj) / bj,

jJ\J0,

(23.2)

xj = 0,

jJ0.

(23.3)

337

Chapter 5: User model PrT

The flow proportions provided by (23.1) to (23.3) implicitly satisfy (21.4). But to state that the
chosen J0 yields the solution of problem (21.1) to (21.4), we still must ensure the following
conditions: aj < v, for each jJ\J0 (as required by (21.3), since xj = (v - aj) / bj > 0), and aj v, for
each jJ0 (as required by (21.2), since xj = 0). This implies that at the solution the value of v
resulting from (23.1) must partition the set J into two sub-sets: the set J0, made up by the
alternatives j such that aj v; and its complement J\J0, made up by the alternatives j such that
aj < v.
At a first glance the problem to determine the set J0 of alternatives with zero flow may seem to
be combinatorial. However, this is not the case. The equation (23.1) can be rewritten as a
recursive formula. It then shows the effect of removing an alternative k from the set J0:
v[J0\{k}] = (v[J0] jJ\J0 1 / bj + ak / bk) / (jJ\J0 1 / bj + 1 / bk).

(24)

The right hand side of (24) can be interpreted as an average between v[J0] and ak with the
positive weights jJ\J0 1 / bj and 1 / bk. Therefore, the local equilibrium cost increases by
removing from J0 any alternative kJ\J0, for which ak is higher than the current value v[J0]. Vice
versa it decreases by adding such alternatives to J0. Consequently, the correct partition set J0
can be simply obtained by adding iteratively to an initially empty set each alternative jJ\J0
such that aj > v, i.e. each alternative for which (23.2) yields a negative flow proportion.

5.13.3

Descent direction
To obtain a complete pattern of arc flows ed for a given destination dZ consistent with the local
user equilibrium we simply have to solve problem (20.1) to (20.4) at each node iN\{d}
proceeding in topological order, where the node flow is computed as follows:
eid = jBSB(i, d) ejid + Did

(25)

We have shown that a given direction is descent if, and only if (13) applies (see "Mathematical
formulation and theoretical framework" on page 332). In terms of arc flows directed to
destination dZ, the following results:
ijA cij (eijd - fijd) < 0,

(26)
d

expressing that the shift of flow from f to e must entail a decrease of total cost with respect to
the current cost pattern. The proof that the proposed procedure provides a descent direction
goes beyond the scope of this description. For more detailed information, please refer to
Gentile G., 2009.
In the following we present an example showing the computation of the descent direction
provided by the LUCE algorithm. We consider the graph of the Braess paradox, with 4 nodes
and 5 arcs.

338

PTV AG

Chapter 5.13: Linear User Cost Equilibrium (LUCE)

Illustration 98: Numerical example of the procedure to obtain the descent direction

The arc cost function is cij = Tij + Qij fij2, so that its derivative is gij = 2 Qij fij.
There is only one destination d = 4, and two origins with travel demand D14 = 9 and D24 = 2. We
consider an initial flow pattern where all available paths, the 3 routes from 1 to 4 and the 2
routes from 2 to 4, are equally used by each OD pair. In this case it is fij = fijd and the bush is
the entire network.
After we evaluate at the current flow pattern the arc costs and their derivatives, we can
compute for each node i the average cost Cid and its derivative Giditeratively starting from the
destination, where Cdd = Gdd = 0, and proceeding in reverse topological order. To this aim we
apply the formulas:
Cid = jFSB(i, d) yijd (cij + Cjd), Gid = jFSB(i, d) yijd 2 (gij + Gjd).

While the computation for node 3 is trivial, since its forward star is a singleton, for node 2 we
have:
C24 = y234 (c23 + C34) + y244 (c24 + C44) = 0.5 (21 + 52) + 0.5 (42 + 0) = 57.5,
G24 = y234 2 (g23 + G34) + y244 2 (g24 + G44) = 0.52 (8 + 14) + 0.52 (16 + 0) = 9.5,

and for node 1 it is:


C34 = y134 (c13 + C34) + y124 (c12 + C24) = 0.33 (29 + 52) + 0.66 (41 + 57.5) = 92.7,
G34 = y134 2 (g13 + G34) + y124 2 (g12 + G24) = 0.332 (12 + 14) + 0.662 (12 + 9.5) = 12.4.

PTV AG

339

Chapter 5: User model PrT

Illustration 99: Numerical example of the procedure to obtain the descent direction

Now we can compute for each node i the node flows eid and the arc flows eijd iteratively by
proceeding in topological order.
To this aim we shall focus on the local route choice of the eid users, whose available
alternatives are the arcs of the bush exiting from node i. To each travel alternative we
associate the cost function:
vij(eijd) = (cij + Cjd) + (gij + Gjd) (eijd - yijd eid),

resulting from a linearization at the current flow pattern of the average cost encountered by a
user choosing arc ij, and we look for an equilibrium. We have shown that the latter can be
determined using the following formulas:
Vid = (1 + jJ aijd / bijd) / (jJ 1 / bijd), eijd = eid (Vid - aijd) / bijd,

where: aijd = (cij + Cjd) - (gij + Gjd) eid yijd, bijd = (gij + Gjd) eid. J is set initially to the forward
star FSB(i, d); if some eijd results to be negative, then it is set to zero, j is removed from J and
the computation is repeated.
We start then with node 1, whose node flow is e14 = D14 = 6:
a134 = (c13 + C34) - (g13 + G34) e14 y134 = (29 + 52) - (12 + 14) 9 0.33 = 3
a124 = (c12 + C24) - (g12 + G24) e14 y124 = (41 + 57.5) - (12 + 9.5) 9 0.66 = -30.5,
b134 = (g13 + G34) e14 = (29 + 14) 9 = 387.
b124 = (g12 + G24) e14 = (41 + 9.5) 9 = 454.5.
V14 = (1 + a134/b134 + a124/b124) / (1/b134 +1/b124) = (1+ 3/387-30.5/454.5) / (1/387+1/454.5) = 196.6,
e134 = e14 (V14 - a134) / b134 = 9 (196.6 - 3) / 387 = 4.5,
e124 = e14 (V14 - a124) / b124 = 9 (196.6 + 30.5) / 454.5 = 4.5.

Then we go on with node 2, whose node flow is e24 = e124 + D24 = 4.50 + 2 = 6.5:
a234 = (c23 + C34) - (g23 + G34) e24 y234 = (21 + 52) - (8 + 14) 6.5 0.5 = 1.5,
a244 = (c24 + C44) - (g24 + G44) e24 y244 = (42 + 0) - (16 + 0) 6.5 0.5 = -10,

340

PTV AG

Chapter 5.13: Linear User Cost Equilibrium (LUCE)

b234 = (g23 + G34) e14 = (8 + 14) 6.5 = 143.


b244 = (g24 + G44) e14 = (16 + 0) 6.5 = 104,
V24 = (1 + a234/b234 + a244/b244) / (1/b234 +1/b244) = (1 +1.5/143 -10/104) / (1/143+1/104) = 55.1,
e234 = e24 (V24 - a234) / b234 = 6.5 (55.1 - 1.5) / 143 = 2.43,
e244 = e24 (V24 - a244) / b244 = 6.5 (55.1 + 10) / 104 = 4.07,

Finally, we consider node 3, whose volume is e34 = e134 + e234 + D34 = 4.5 + 2.43 + 0 = 6.93:
Since there is only one alternative, the following applies: e344 = e34 = 6.93. Only for completeness we compute V34 as follows:
V34 = (c34 + C44) + (g34 + G44) (e344 - e34 y344) = (52 + 0) + (14 + 0) (6.55 - 6.93 1) = 46.7.

The flow pattern we have just found is a descent direction because we have:
ijA fijd cij = 949 > ijA eijd cij = 897.

The illustration 98 represents the AON assignment to shortest paths (marked by *). The
illustration 99 displays the equilibrium flow and cost pattern (marked by *). It can be seen that
one single iteration of the proposed descent direction allows a substantial step towards the
solution.

5.13.4

Assignment algorithm
Below we provide a pseudo code of the procedure within the framework of an assignment
algorithm.

function LUCE
f = 0
initialize the solution flows to zero
perform n iterations
for k = 1 to n
for each destination d
for each dZ
for each ijA
compute arc costs and their derivatives
cij = cij( fij)
gij = max{cij( fij)/fij, }
if fid > 0 then yijd = fijd / fid else yijd = 0
B(d) =B(B(d), c, f)
initialize or modify the current bush
Cd d = 0
the average cost of the destination is zero
Gdd = 0
so its derivative
for each i:ijB(d) in reverse topological order for each node i d in the bush
if fid > 0 then
Cid = jFSB(i, d) yijd (cij + Cjd)
compute the node average cost to d
and its derivative
Gid = jFSB(i, d) yijd 2 (gij + Gjd)
else
Cid = min{cij + Cjd: jFSB(i, d)}
Gid = jFSB(i, d) [Cid = cij + Cjd] (gij + Gjd) / jFSB(i, d) [Cid = cij + Cjd],
d
e = 0
reset the arc and node flows to d
for each oZ
load on the origins the demand to d
eod = Dod
for each i:ijB(d) in topological order for each node i d in the bush
J = FSB(i, d)
initialize the set of arcs with positive flow
= 0
until = 1 do
PTV AG

341

Chapter 5: User model PrT

=1

Vid = [eid + jJ (cij + Cjd) / (gij + Gjd) - eidyijd] / jJ 1/(gij + Gjd)


for each jJ
eijd = Vid / (gij + Gjd) - (cij + Cjd) / (gij + Gjd) + eidyijd
if eijd < 0 then
eijd = 0
J = J \ { j}
remove ij from the set of arcs with positive flow
=0
then repeat the procedure
for each jJ
propagate the arc flows to the head node flows
ejd = ejd + eijd
= 1
if k > 1 then
armijo step
until ijA cij( fij + (eijd - fijd)) (eijd - fijd) < 0 do = 0.5
update arc flows
for each ijA
fij = fij + (eijd - fijd)
fijd = fijd + (eijd - fijd)

The bush of each destination dZ is initialized with the set of efficient arcs that bring closer to
the destination, where the minimum costs are evaluated at zero flow. At the generic iteration,
any non-efficient arc on the bush carrying no destination flow is removed from it, while any arc
that would improve shortest paths on the bush is added to it, if its reverse arc does not carry
destination flow. If the resulting sub-graph is acyclic, then it is substituted to the current bush
of that destination. Since the LUCE algorithm tends to an equilibrium on the bush, eventually
the flow on non-efficient paths disappears and the bush can be properly modified.
Note that, beside the initialization of the bushes, the LUCE algorithm does not require shortest
path computations, but only simple visits of the bushes.

5.13.5

Input and output attributes of the equilibrium assignment (LUCE)


For the equilibrium assignment (LUCE), the same input attributes are required as for the
equilibrium assignment (table 109).
After calculation, the results are available in the output attributes and can be displayed in the
list view (see User Manual, Chpt. 12.1, page 1369) or in the network editor (see User Manual,
Chpt. 12.2, page 1400).
Tip: This hint might help to reduce the LUCE run time by means of specific network modeling.
Internally, LUCE has to explode a node to generate several sub-nodes and connecting links
between these sub-nodes, if the turns via the node have different impedances of if some of
these turns are not open. Due to this, the graph on which the procedure works will be
extended which again means an increase in the run time. If you do not want to model the
turns explicitly in your network model, make sure that also the U-turns are permissible for all
private transport systems. Otherwise, Visum has to explode all nodes because of the blocked
U-turns. By default, all turns are open in Visum, U-turns included. If there are no aspects that
contradict, you should open the blocked U-turns in your network, too. For more details
regarding the transport system set recalculation at turns and main turns, please refer to the
given chapters: (see User Manual, Chpt. 2.13.6.4, page 274) and (see User Manual, Chpt.
2.20.6.4, page 357). This will not have any negative effect on the created routes, since Uturns are never included in loaded routes as long as none of the turns has been modeled
explicitly.

342

PTV AG

Chapter 5.13: Linear User Cost Equilibrium (LUCE)

5.13.6

Persistent storage of bushes


For each demand segment, the routes and route volumes are stored as bushes in the version
file.
Bushes are regarded for the following operations on paths:

Skim matrix (also for a freely definable skim) in case of route-based assignments:
for the Minimum weight, always the shortest path is used for calculation
for the Mean over route volumes weight, the shortest path is used only if the OD pair
is not in the bush; otherwise, the skim data is weighted with the volumes of the edges
from the origin to the destinations.
Flow bundle
TFlowFuzzy
COM: TFlowMatrix
OD pair filter
Blocking back
Generate demand matrix from paths

Furthermore, they are regarded for the following operations:

Paths list output


Draw paths
COM (Paths interface)
Route export
Subnetwork generation
ANM export
Demand matrix calibration
Optimization of the signal timing coordination

The following operations cannot be applied to LUCE paths:

5.13.7

Conversion into PrT paths or vice versa


Changes to the course or the volume of a path
Route import

Start from an initial assignment


Like other PrT assignment methods, also LUCE can use an existing assignment result as initial
solution to save computation time during the next run if supply and demand had changed only
slightly. Prerequisite: The existing assignment needs to be a LUCE result and the path
information (bushes) must have been stored. Different PrT assignments cannot start with a
LUCE result as initial solution and vice versa.

PTV AG

343

Chapter 5: User model PrT

5.13.8

Optimizing the proportionality in the route distribution


According to Wardrop's equilibrium condition the link volumes are determined explicitly, but the
path volumes are not necessarily. This is clearly illustrated in the example in illustration 100.

Illustration 100: Example for the proportionality with balanced link volumes

The zones 1 and 2 are connected to node A, the zones 3 and 4 are connected to node B. A
and B are connected by the two links x and y, which have the same VDF. Demand is 500 trips
each from 1 to 3 and from 1 to 4. The image shows the resulting link volumes in the balanced
state. But the link volumes can result from the various route volumes overlaying on the links.
Three of them are listed in the table:
Volume

Variant 1

Variant 2

Variant 3

1-x-3

200

500

250

1-y-3

300

250

1-x-4

300

250

1-y-4

200

500

250

Table 112: Variants of route volumes for the link volumes in illustration 100

With regard to the impedance balance, all variants are equivalent, though variant 3 has the
advantage that the route distribution at node A is proportional for the relations to the zones 3
and 4. Since the links x and y have the same impedance one cannot assume that at node A
road users on their way to the destination x will not distribute to the links in the same way as
those heading to destination y.
Due to the separate handling of the OD pairs, the path-based equilibrium procedure could
generate any of the indefinite number of path volume variants arbitrarily, whereas LUCE
always charges the paths proportionally as shown in variant 3. But this advantage is based on
the fact, that LUCE simultaneously balances all path volumes to an origin zone. Identical turn
proportions can therefore be generated within an origin zone only, they are not reached for the
routes of various origin zones.
This is illustrated by the extended example in illustration 101, now with 500 trips each between
the zones 2 and 3, and 2 and 4. Again, the image shows balanced link volumes.

344

PTV AG

Chapter 5.13: Linear User Cost Equilibrium (LUCE)

Illustration 101: Extended example for the proportionality with balanced link volumes

Even though the route distributions to the paths within an origin zone show consistent shares,
this does not apply to the paths of different origin zones. Again various volume variants can be
generated:
Volume

Variant 1

Variant 2

Variant 3
250

1-x-3

200

500

1-y-3

300

250

1-x-4

200

500

250

1-y-4

300

250

2-x-3

300

250

2-y-3

200

500

250

2-x-4

300

250

2-y-4

200

500

250

Table 113: Variants of route volumes for the link volumes in illustration 101

For the same reason as above, variant 3 is the preferable variant, since there is no need for
unequal loading of the routes. However, this balancing procedure cannot be performed in a
purely origin-based way. LUCE provides the option to harmonize the path volumes over all
origin zones subsequently to the determination of meshes of the same impedance (compare
mesh A-B in the example) which is based on the paths that were calculated during the actual
assignment. This is always the case, since in an isolated view the mesh is in a balanced state;
thus, volumes can be shifted between the path alternatives from different origin zones without
any changes to the link volumes or impedances. Thus, the equilibrium state can be retained.
Since mesh finding and route choice optimization are time-consuming this procedure is
provided as an option which can additionally be activated in the LUCE procedure parameters.
For the reliable detection of balanced meshes the assignment should have finished with a gap
of 10-6 or better. In this case, the optimization of the route distribution will additionally take
another 20% - 50% of the assignment run time.
The optimization of the route distribution is highly recommended if route volumes shall be
analyzed or used in further computations. This applies to the following operations:

PTV AG

Matrix estimation though TFlowFuzzy


Flow bundles (especially flow matrix analyses)
Blocking back model

345

Chapter 5: User model PrT

But if primarily link-related assignment results are required (volumes, travel times), then
optimization is not required, since this would not improve the given results.

5.14

Equilibrium_Lohse
The Equilibrium_Lohse procedure was developed by professor Lohse and is described in
Schnabel (1997). This procedure models the learning process of road users using the network.
Starting with an "all or nothing assignment", drivers consecutively include information gained
during their last journey for the next route search. Several shortest routes are searched in an
iterative process whereby for the route search the impedance is deduced from the impedance
of the current volume and the previously estimated impedance. To do this, the total traffic flow
is assigned to the shortest routes found so far for every iteration step.
During the first iteration step only the network impedances in the free network are taken into
account (like 100 % best-route assignment).
The calculation of the impedance in every further iteration step is carried out using the current
mean impedances calculated so far and the impedances resulting from the current volume, i.e.
every iteration step n is based on the impedances calculated at n-1.
The assignment of the demand matrix to the network corresponds to how many times the route
was found ("kept in mind" by Visum).
The procedure only terminates when the estimated times underlying the route choice and the
travel times resulting from these routes coincide to a sufficient degree; there is a high
probability that this stable state of the traffic network corresponds to the route choice behavior
of drivers.
To estimate the travel time for each link of the following iteration step n+1, the estimated travel
time for n is added to the difference between the calculated actual travel time of n (calculated
from the VD functions) and the estimated travel time of n. This difference is then multiplied by
the value DELTA (0.15...0.5) which results in an attenuated sine wave.
The termination condition arises from the requirement that the estimated travel times for
iteration steps n and n-1, and the calculated actual travel time of iteration step n, sufficiently
correspond to each other. This is defined by the precision threshold EPSILON.

5.14.1

Example of the Equilibrium_Lohse procedure


The Equilibrium_Lohse procedure is demonstrated below with a calculation example. The
table 114 shows the parameter settings of the Equilibrium_Lohse and the impedance for links
and routes in the unloaded network. The table 115, table 116 and table 117 then show three
iterations of the calculation process.
LinkNo
1

Type

Length [m]
20

5,000

v0 [km/h]

Capacity [car units]


100

R0* [min]

1,200

03:00

20

5,000

100

1,200

03:00

20

5,000

100

1,200

03:00

20

5,000

100

1,200

03:00

Table 114: Impedance in unloaded network, input parameters of Equilibrium_Lohse method

346

PTV AG

Chapter 5.14: Equilibrium_Lohse

LinkNo

Type

Length [m]

v0 [km/h]

Capacity [car units]

R0* [min]

20

5,000

100

1,200

03:00

20

5,000

100

1,200

03:00

30

16,000

80

800

12:00

30

5,000

80

800

03:45

10

40

10,000

60

500

10.00

11

40

5,000

60

500

05:00

Table 114: Impedance in unloaded network, input parameters of Equilibrium_Lohse method


Route

Links

Length [m]

1+8+9

26,000

R0* [min]
0:18:45

1+2+3+5+6+7

30,000

0:18:00

10+11+5+6+7

30,000

0:24:00

Input parameters:

BPR function with a = 1, b = 2, c = 1


LowerLimit = 0.15
UpperLimit = 0.5
V1 = 2.5

V2 = 4
V3 = 0.002

2.5

f ( TT ) = ----------------------------------------

1+e

4 0.002 TT

LinkNo Volume 1 [car units] R1 [min]

TT1

f(TT1)

Delta 1

R1* [min]

2.78

0.0452

0.4796

07:00 a.m.

2,000

11:20 AM

2,000

11:20

2.78

0.0452

0.4796

07:00

2,000

11:20

2.78

0.0452

0.4796

07:00

2,000

11:20

2.78

0.0452

0.4796

07:00

2,000

11:20

2.78

0.0452

0.4796

07:00

2,000

11:20

2.78

0.0452

0.4796

07:00

12:00

0.00

0.0450

0.5000

12:00

03:45

0.00

0.0450

0.5000

03:45

10

10.00

0.00

0.0450

0.5000

10:00

11

05:00

0.00

0.0450

0.5000

05:00

Route

Volume 1

R1

R1*

0:27:05

0:22:45

Table 115: Example of Equilibrium_Lohse: 1st iteration step

PTV AG

347

Chapter 5: User model PrT

Route

Volume 1

R1

R1*

2,000

1:08:00

0:41:59

0:49:00

0:35:59

Table 115: Example of Equilibrium_Lohse: 1st iteration step

LinkNo

Volume 2 [car units] R2 [min]

TT2

f(TT2)

Delta 2

R2* [min]

2,000

11:20

0.62

0.0450

0.4925

09:08

1,000

05:05

0.27

0.0450

0.4962

06:03

1,000

05:05

0.27

0.0450

0.4962

06:03

1,000

05:05

0.27

0.0450

0.4962

06:03

1,000

05:05

0.27

0.0450

0.4962

06:03

1,000

05:05

0.27

0.0450

0.4962

06:03

1,000

30:45

1.56

0.0451

0.4855

21:06

1,000

09:37

1.56

0.0451

0.4855

06:36

10

10.00

0.00

0.0450

0.5000

10.00

11

05:00

0.00

0.0450

0.5000

05:00

Route

Volume 2

R2

R2*

1,000

0:51:42

0:36:50

1,000

0:36:45

0:39:22

0:30:15

0:33:08

Table 116: Example of Equilibrium_Lohse: 2nd iteration step

348

LinkNo

Volume 3 [car units] R3 [min]

TT3

f(TT3)

Delta 3

R3* [min]

1,333

0.27

0.0450

0.4963

07:56

06:42

667

03:56

0.35

0.0450

0.4953

05:00

667

03:56

0.35

0.0450

0.4953

05:00

1,333

06:42

0.11

0.0450

0.4984

06:22

1,333

06:42

0.11

0.0450

0.4984

06:22

1333

6:42 AM a.m. 0.11

0.0450

0.4984

06:22

667

20:20

0.0450

0.4994

20:43

0.04

667

06:21

0.04

0.0450

0.4994

06:28

10

667

27:47

1.78

0.0451

0.4842

18:37

11

667

13:53

1.78

0.0451

0.4842

09:18

PTV AG

Chapter 5.14: Equilibrium_Lohse

Route

Volume 3

R3

R3*

667

0:33:23

0:35:07

667

0:34:40

0:37:03

667

1:01:47

0:47:02

Table 117: Example of Equilibrium_Lohse: 3rd iteration step

The table 114, table 115, table 116 and table 117 illustrate the first three iteration steps of the
Equilibrium_Lohse procedure for the example network.

Iteration step 1, n = 1

Volume 1
The volume of the first iteration step results from an "all or nothing" assignment onto the
lowest impedance route in the unloaded network. For impedance R0*, this is route 2 loaded
with 2,000 car trips.

Current impedance R1
The current impedance R1 of every link results from the BPR capacity function (a =1, b = 2,
c= 1). For link 1, for example, the following can be calculated:
R1 (link 1) = 3 min x (1+(2,000/1,200)) = 11 min 20s

Estimated impedance R1*


The estimated impedance R1* of every link consists of the current impedance R1 and the
estimated impedance R0* of the last iteration step. It results from the learning factor . To
determine R1* for link 1, the following calculations are necessary:

R0* = 3 min = 180 s

R1 = 11 min 20s = 680 s

TT1 = |R1 - R0*| /R0* = |680 s - 180 s| / 180 s = 2.78

V1
2.5
- = -------------------------------------------f ( TT 1 ) = ------------------------------------= 0.0452
V 2 V 3 TT 1
4 0.002 2.78
1+e
1+e
1 = Bottom +

Top Bottom
0,5 0,15
= 0.15 +
= 0.4796
(
)
f
TT
(1 + TT1 ) 1
(1 + 2.78)0.0452

R1* = R0* + 1 (R1 - R0*) = 180 s + 0.4796 (680 s - 180 s) = 420 s

Iteration step 2, n = 2

Volume 2
The lowest impedance route for R1* is route 1. Now two routes exist, route 1 and 2. Each
route is loaded with 1/n, i.e. the demand, so that each route is used by 1,000 cars.

Current impedance R2
The current impedance R2 of every link increases on newly loaded links 8 and 9, and it
decreases on links 2, 3, 5, 6 and 7.

PTV AG

349

Chapter 5: User model PrT

Estimated impedance R2*


The estimated impedance R2* of every link consists of the current impedance R2 and the
estimated impedance R1* of the last iteration step.

Iteration step 3, n = 3

Volume 3
The lowest impedance route for R2* is route 3. 2,000 car trips are now equally distributed
across routes 1, 2 and 3.

Current impedance R3
The current impedance R3 again results from the current volume 3 via the VD function.

Estimated impedance R3*


The estimated impedance R3* of every link consists of the current impedance R3 and the
estimated impedance R2* of the last iteration step.

Iteration step 4, n = 4
The concluding route search based on R3* determines route 1 as the shortest route. Thus, the
following route volumes result:

5.14.2

Volume route 1 = 2/4 2,000 = 1,000 trips


Volume route 2 = 1/4 2,000 = 500 trips
Volume route 3 = 1/4 2,000 = 500 trips

Input and output attributes of the Equilibrium_Lohse procedure


To execute the Equilibrium_Lohse procedure, certain entries must be made. After calculation,
the results are available in the output attributes and can be displayed in the list view (see User
Manual, Chpt. 12.1, page 1369) or in the network editor (see User Manual, Chpt. 12.2,
page 1400). The table 118 gives an overview of which input attributes have to be maintained.
The table 119 lists the output attributes which store the results of the procedure.

350

PTV AG

Chapter 5.14: Equilibrium_Lohse

Table 118: Input attributes of the Equilibrium_Lohse procedure

The abbreviations represent the following:

PTV AG

x1

Toll PrTSys has to be inserted manually in the impedance function

(X)

Can be used optionally

(*)

Apart from the parameters which are directly set in the assignment procedure

351

Chapter 5: User model PrT

Table 119: Output attributes of the Equilibrium_Lohse procedure

352

PTV AG

Chapter 5.14: Equilibrium_Lohse

5.14.3

Procedure of the Equilibrium_Lohse assignment


The succeeding steps in the Equilibrium_Lohse procedure are illustrated by illustration 102.

Input

Upper and lower threshold of delta: upper and lower


parameters of the f(TT) function: V1, V2, V 3
Termination conditions: max. number iterations N;
E1, E2, E3 for determining the max. deviation E of impedance

n = 0, R n=0* = Impedance in unloaded network

n=n+1

Route
search

Route
volumes

Determination of shortest route rn for all OD pairs based on


impedance Rn-1*
If route rn is new route r: Count r = 1
If route rn already exists as router : Countr = Countr +1

Determine volumes for all routes of any relation ij:


Route volume qr = (Fij / n) Countr

Rn = impedance at current volume n

TTn = Rn R *n 1 R *n 1
Impedance
determination

f (TTn ) = V1 (1 + e V2 V3 TTn )
n = lower +

upper lower
(1 + TTn ) f (TTn )

R*n = R*n 1 + n (Rn Rn*1 )

Query

no

n = N or for every link applies:

Rn R

*
n 1

< E = E1 Rn 1

E2 / E3

yes
End
Illustration 102: Procedure of the Equilibrium_Lohse assignment

PTV AG

353

Chapter 5: User model PrT

5.14.4

Evaluation of the Equilibrium_Lohse procedure


Under the condition that a sufficient number of iteration steps (N > 40) are carried out and that
the procedure is not terminated due to the condition n = N, the Equilibrium_Lohse method
produces realistic, stable results. Even in networks with low saturation, the distribution of
volumes onto alternative routes is good. The greater number of iteration steps necessary for a
good solution usually requires more route searches than the equilibrium assignment. This
results in longer computing times.

5.15

Assignment with ICA


Compared to other procedures, using volume-delay functions by lane which are permanently
re-calibrated by means of ICA causes a significantly improved convergence behavior, since
the lane geometry and interdependencies between the individual turns via a node are regarded
in detail.

5.15.1

Fundamental principle
In Visum, any variant of the equilibrium assignment uses volume-delay functions for links and
turns to model the impedance that increases with increasing volumes. In urban network
models, the Turn VDFs are of particular importance, since the nodes affect the network
performance to a much greater extent than links do. The mathematical formulation of the
assignment problem assumes, that the impedance which is calculated by the VDFs depends
only on the volume and the capacity of the individual network object (link, turn). Volume delay
functions with this property are called separable VDFs. In reality, this holds approximately for
links, but it does not apply to turns via nodes. Typical counter-examples are the permitted turns
at signalized nodes or turns from minor approaches at two-way nodes. In these cases, the
impedance does not only depend on the volume of the turn itself, but also from the volumes of
the conflicting flows, i.e. the volumes of other turns via this node. Thus, the associated volumedelay functions can no longer be separable. This is a problem for the mathematical solution of
the assignment problem, since existence and uniqueness of the equilibrium solution require
separable volume-delay functions.
Two requirements can be derived from this analysis:

354

Realistic impedance modeling for nodes premises that nodes are modeled in detail in a way
that conflicts between turns can be identified correctly. Transferred to Visum this means,
that for these nodes the geometry and control have to be modeled in the junction editor.
Subsequently, precise impedances and capacities of the turns can be calculated using the
Intersection Capacity Analysis (ICA).
For lack of separability, the values calculated by means of ICA may not directly be used to
replace the volume-delay functions in the assignment procedure, since the convergence
would get lost then.

PTV AG

Chapter 5.15: Assignment with ICA

Illustration 103: ICA-based impedance calculation

Visum by-passes the separability problem by an approximation approach. The procedure


consists of an interaction between an equilibrium assignment procedure (using conventional
VDFs) and node impedance calculation (ICA). First, equilibrium assignment is used to
calculate the turn volumes. After the assignment, blocking back calculation ensures that the
volumes used for ICA are realistic, i.e. do not lie in the overloaded range. ICA is then used to
calculate the turn capacities and wait times for volumes. Subsequently, the volume of each turn
is varied, while volumes of the other turns at the same node are retained in order to calculate
wait times for other volume conditions. The wait times calculated for the individual turns are
interpolated to estimate a CR function. These turn-specific VD functions are used in the next
equilibrium assignment. They model the dependence of the impedance on only the turn
volume while the conflicting flows are regarded as if being constant. From the assignment's
point of view, the effect of conflicting flows is "frozen" thereby until (after more equilibrium
iterations) these flows are also updated in the next ICA calculation. In this way, the volumedelay functions are stabilized for some iterations in each case to favor convergence. As
blocking back calculation is performed after the assignment, additional wait times might occur
due to a traffic jams. They, however, must be considered for route search and choice of the
subsequent equilibrium assignment. This is achieved by manipulating the assigned link VD
function in the range exceeding effective capacity, so that the wait time of blocking back
calculation is depicted in the VD function. In contrast to link capacity, effective capacity
accounts for the actual flow through rate of a link, which might lie below capacity due to
spillback congestion. Adaptation of the link VD function is only done for links that, similar to
modeled nodes, typically lie in the center of the examined area. The feedback loop between
assignment and ICA ends, as soon as the impedances calculated by the VD function or ICA do
no longer significantly differ. For all other links and connectors, the assignment with ICA uses
regular VD functions, where applicable. Their parameters do not depend on the individual
network object, however, for links they depend on the link type only.

PTV AG

355

Chapter 5: User model PrT

5.15.2

Evaluation of the Assignment with ICA


The assignment with ICA is a static and accounts for detailed node impedances.
Specific advantage: Normally ICA cannot be applied properly while an assignment is running,
since the VD functions are not separable. In the approach described, turn VD functions are
made "roughly separable" by "freezing" the conflicting flows in equilibrium assignment.
Normally, convergence is reached in this way. Simultaneously, the Turn VDFs are
continuously adjusted to the wait times and capacities calculated by ICA. The HCM 2000
method (HCM 2000 or HCM 2010) used by ICA is one of the most highly approved analysis
methods for node performance calculations and considers the lane distribution and conflicting
turns in detail.
The disadvantage is the significantly higher time and effort for modeling and calibration, since
nodes whose impedances are to be calculated by ICA have to be modeled in detail. If you do
not want to model all nodes in detail in your network model you should make sure that for the
other nodes volume-delay functions are used which provide impedance data in a comparable
scale. The route choice will be distorted if mixed impedances are produced by ICA turns and
non-ICA turns systematically: Then, for example, only routes are chosen that do not traverse
ICA nodes.
Using the iterative approach, assignment with ICA requires more computation time than a
conventional equilibrium assignment. Additional spillback and ICA calculations are required.
Adaptation of the turn VD functions after subordinate equilibrium assignment mostly leads to a
setback in convergence, which must be offset through recalibration.
As in other assignment procedures, you can use existing assignment results as a starting point
for an assignment with ICA in order to save time. The assignment results used must stem from
an assignment with ICA. Only then is it guaranteed that the attributes used at turns and links
have been calculated. This procedure can be used to calculate scenarios in which the network
basis and demand data do not radically change. The parameters previously estimated thus
form a good basis for recalibration.
For the assignment with ICA, one of the subordinate assignment procedures you can use is
LUCE equilibrium assignment. You might prefer this procedure for assignment with ICA for the
following reasons:

356

With the Use current assignment result as initial solution option set by default. the
assignment times required for subordinate LUCE assignment are short.
Stable route distribution, especially with option Optimization of the proportionality of
route volumes at meshes.
Calculation of the blocking back model, using so-called bushes, is considerably faster than
conventional calculation methods.
Due to the stable routes, also the blocking back result is more stable and thus convergence
can be reached sooner.

PTV AG

Chapter 5.15: Assignment with ICA

5.15.3

Input and output attributes of the assignment with ICA


Prior to the calculation of an assignment with ICA, certain attributes of network objects and also
procedure parameters have to be set. After calculation, the results are available in the output
attributes and can be displayed in the list view (see User Manual, Chpt. 12.1, page 1369) or in
the network editor (see User Manual, Chpt. 12.2, page 1400). The table 120 gives an overview
of which input attributes have to be maintained. It is important that for those nodes whose turn
impedances you want to calculate in detail using ICA, you select the Node impedance
calculation (ICA) option for the Method for impedance at node attribute and set the Use
preset method for impedance at node attribute to TRUE. The table 121 lists the most
important output attributes of the procedure for turns.
The following prerequisites are required for the assignment with ICA:

PTV AG

Prior to the assignment with ICA calculation, the geometry and control need to be modeled
correctly for the nodes the ICA impedance calculation has been activated for. To check
whether the calculation can be performed correctly for all nodes, from the Calculate menu,
choose >Network check and check the Viability for ICA option.
For turns, the design volume PrT needs to be a volume-representing attribute (Volume PrT
or Volume PrT with base). Enter the settings via menu Calculate > General procedure
settings > navigator entry PrT settings > Node impedances. For the design volume PrT,
only factor 1.0 is permitted. This is due to the fact, that the calibration of the VDFs by turn
would fail otherwise. The VD function used for turns is based on the hourly capacities
output by ICA. This means that you can only perform assignment with ICA for assignment
periods of 1h. As a result, hourly values for link and turn capacities must be defined.

357

Chapter 5: User model PrT

Table 120: Input attributes of the assignment with ICA

358

PTV AG

Chapter 5.15: Assignment with ICA

The abbreviations represent the following:


x1

Toll-PrTSys has to be inserted manually in the impedance function to have an effect

x2

Takes effect in the framework of the blocking back model

(x)

Can be used optionally

For the output of results, the following options are provided:


There are different output variants: Primarily, the assignment with ICA fills the usual attributes
of the various network object types (link, turn, etc.) with the calculated volumes and
impedances. In addition to the common volume and travel time attributes, there are the
following output attributes at (main) turns and links that are only filled through assignment with
ICA:
Attribute

Meaning

Is ICA turn in ICA assignment

Indicates whether the ICA-Turn function is to be used for this turn in the
assignment with ICA.

Final capacity for assignment


with ICA

Last capacity used during assignment with ICA. The Capacity PrTV
attribute is not used for turns at (main) nodes calculated with ICA.

Final t0 for assignment with


ICA

t0 that was recently used with ICA assignment. The t0 PrT attribute is
not used for (main) turns at nodes calculated with ICA.

Final smoothed volume for


assignment with ICA

Smoothed volume resulting from recent iteration.

tCur-PrTSys for assignment


with ICA

tCur of the turn-specific VD function, including the final VD function


parameters. In contrast, the attribute tCur-PrTSys stores the result
calculated in the recent ICA calculation.

Final A for assignment with


ICA

Final VD function parameter A for the turn-specific VDF

Final B for assignment with


ICA

Final VD function parameter B for the turn-specific VDF

Final capacity for assignment


with ICA

corresponds to smoothed capacity of (main) turns calculated with ICA

Deterred upstream volume in


assignment with ICA

Deterred volume refers to the part of the volume that, according to


blocking back calculation, is held back at bottlenecks upstream from the
(main) turn and so does not reach it.

Table 121: Additionally calculated turn/main turn attributes for assignment with ICA
Attribute

Meaning

Effective capacity for


assignment with ICA

On uncongested links, effective capacity corresponds to link capacity or


the Capacity PrT attribute. On congested links, it corresponds to the
traffic volume exiting the link.

Deterred upstream volume in


assignment with ICA

Deterred upstream volume refers to the part of the volume that,


according to blocking back calculation, is held back at bottlenecks
upstream from the (main) turn and so does not reach it.

Table 122: Additionally calculated link attributes for assignment with ICA

PTV AG

359

Chapter 5: User model PrT

Furthermore, numerous diagnostic outputs are provided which can be used for convergence
check. If the procedure converges either slowly or not at all, the outputs provide useful
information, e.g. which turns show significant differences when calculated with ICA impedance
calculation or the VD function.

As long as the procedure is running, you can watch the process in the "Goodness of PrT
assignment with ICA" list.
*.csv files are created to which the program saves turn attribute data after each iteration.
These files are helpful when you want to compare the development of attribute values of
individual turns during the course of assignment with ICA.
Some result attributes of the assignment with ICA are saved to user-defined attributes, if
required. This data can be used for the comparison of the convergence reached in different
runs of the assignment with ICA. To do so, first copy the values of the user-defined
attributes, before they are overwritten during the next calculation.
Optionally, an Excel report is created which contains the results of the recent ICA
calculation. From the report it is to be seen, which volumes were used for the calculation
and which capacities resulted from that. For nodes of the all-way stop type, the v/c value is
output the same way as for nodes of the two-way stop type.

The precise times, when attribute data is stored in an iteration is described with the procedure
(see "Procedure of the Assignment with ICA" on page 360).

5.15.4

Procedure of the Assignment with ICA


The assignment with ICA is based on the iterative solution for the user optimum with volumedelay functions for all network objects. The distinctive feature is that the parameters of the turn
VD functions can be set by turn ("turn-specific) and might change during the calculation due to
the adjustment of the ICA calculation results, as described with the fundamental principle (see
"Fundamental principle" on page 354).

360

If the assignment with ICA is not based on existing assignment results, the parameters
used in the VD function for turns and links are first initialized. For turns, the input values are
used that you have specified in the Procedure parameters window (Input tab). Depending
on the control type used, additional signal times and geometric data are considered. The
parameters initialized for turn capacities, t0, and the VD functions A and B are used to
perform the first subordinate assignment. The link attribute Effective capacity in
assignment with ICA is initialized with the Capacity PrT value. If your assignment with
ICA is based on existing assignment results, the parameters are available from the last
assignment with ICA and initialization is skipped.
First the subordinate assignment procedure is performed. Choose one of the following
assignment procedures: Equilibrium assignment, Equilibrium_Lohse or Equilibrium
assignment (LUCE). For nodes, for which ICA calculation has been activated, use turnspecific VD functions. In this case, no ICA calculations are carried out during the
subordinate assignment procedure.
The turn-specific VD functions used and the adaptation of link VD functions are described
in separate paragraphs (illustration 104).

PTV AG

Chapter 5.15: Assignment with ICA

After completion of the subordinate assignment procedure, the blocking back model is
applied. For calculation of the blocking back model, the turn capacities at nodes calculated
with ICA are taken into account.. Optionally, you may additionally use the capacities
defined in the link capacity model. The link impedance results obtained through blocking
back model calculation are adjusted in order to account for the additional wait times caused
by traffic jams on the links.
Notes: By applying the blocking back model, only phase 1 is calculated.
The blocking back model is not applied while the subordinate assignment procedure is
performed.
During finalization of the ICA assignment, the global parameters of the blocking back
model (see User Manual, Chpt. 5.5.2, page 1008) are adapted to the procedure
parameters of ICA assignment, i.e. settings that differ are first ignored during ICA
assignment and then overwritten.

PTV AG

Prior to the ICA calculation, the current values are determined for volume and impedance
and also the parameters of the VDFs are recorded (according to the settings: in attribute
files, as user-defined attributes and in the Goodness of PrT assignment with ICA list).
Then, the turn volumes calculated in the recent iteration and in the current iteration are
smoothed, i.e. the weighted mean is calculated.
Using ICA, the program calculates turn impedances and capacities. For this ICA
calculation, the design volume used is the smoothed turn volume (including the basic
volume, depending on the design volume set).
Calculation of the new, turn-specific VD functions is performed in two steps and separately
for each turn. In the first step, the parameters of the VD function are determined through
interpolation of three sampling points. One sampling point is given by the smoothed turn
volumes and the respective impedance (see previous step). To determine two additional
sampling points, reduce or increase the volume of the turn currently being processed, while
maintaining the other turn volumes passing via the node. The impedance of the current turn
is then recalculated with ICA. Since the VD function to be interpolated possesses three free
parameters (t0, A, B), it is clearly defined by the three sampling points. In the second step,
these parameters and also the capacity are smoothed by means of the values resulting
from the previous iteration. In the procedure parameters, a minimum capacity per turn can
be set. If the smoothing result is below the minimum capacity, the minimum capacity will be
used instead. The convergence check is performed after the determination of the new
VDFs. If the convergence constraints are satisfied, the parameters of the VDF will be reset
to the value of the recent iteration. This means the VD functions are in accordance with the
subordinate assignment last performed. In the flow diagram, qTn represents the volume of
turn T in iteration n.
If the convergence test is failed, the attributes Deterred upstream volume in assignment
with ICA, for links and turns, and Effective capacity in assignment with ICA, for links,
are updated. These values are required for application of the VD function during the next
subordinate assignment (or for an assignment based on existing assignment results).

361

Chapter 5: User model PrT

362

PTV AG

Chapter 5.15: Assignment with ICA

Illustration 104: Procedure of the assignment with ICA

5.15.5

VD functions in assignments with ICA


The following sections describe the turns VD function and adjustment of the links VD function
during assignment with ICA

5.15.5.1 Used turn VDF


The turns VD function is used for assignment with ICA of all opened turns whose nodes include
a Node impedance calculation (ICA).
B

max ( 0, q q-
t 0 + A ----------------------------------
cap
t cur ( q, cap, t 0, A, B, q ) =
t + A
else
0

if q q cap

Thereby
tcur

PTV AG

Turn attribute corresponds to tCur of the turn-specific VD function including the VD function
parameters. Attribute tCur_PrTSys for assignment with ICA contains the value calculated
at the end of the assignment with ICA.

363

Chapter 5: User model PrT

A and B

Attributes of the respective turns.


The attributes Final A for assignment with ICA and Final B for assignment with ICA
include the values calculated at the end of the assignment with ICA.

q
t0

Turn volume in subordinate assignment (without spillback congestion)

cap

Turn attribute that corresponds to smoothed capacity in the assignment with ICA.
Attribute Final capacity for assignment with ICA contains the value calculated at the end
of the assignment with ICA.

Turn attribute calculated as the difference between demand volume and volume. Deterred
volume refers to the part of the volume that, according to blocking back calculation, is held
back at bottlenecks upstream from the turn and so does not reach it.
Attribute Deterred volume upstream in assignment with ICA contains the value
calculated at the end of the assignment with ICA.

Turn attribute
Attribute Final t0 for assignment with ICA contains the value calculated at the end of the
assignment with ICA.

During the assignment, the factors A and B are updated with each ICA impedance calculation
per turn. You can find the values of the last iteration in the turn attributes Final A for
assignment with ICA and Final B for assignment with ICA. The following data are also
saved to turn attributes: t0 values (Final t0 for assignment with ICA), the capacity (Final
capacity for assignment with ICA), and the difference between demand volume and current
volume (Deterred volume upstream in assignment with ICA).

5.15.5.2 Adapting the link VD functions used


Generally, link VD functions are conventionally assigned during the assignment with ICA, so
you can define link VD functions based on the link type. For links with traffic jams according to
blocking back calculation, the VD functions you defined are adjusted according to the formula,
i. e. your VD functions are used to calculate volumes up to effective capacity and are then cut
off. For volumes exceeding effective capacity, the congestion wait time is calculated instead
(second term of "else" case).
vdf base ( max ( 0, q q ) )
if q q effcap

t cur ( q, cap, effcap, q ) =


T
else
vdf base ( effcap ) + ---------------- ( q effcap q )
effcap

Thereby

364

tcur

Link run time in loaded network

vdfbase

VD function defined (depends on link type)

q
cap
effcap

Link volume in subordinate assignment (without spillback congestion)


Link capacity
Link attribute calculated in each iteration after spillback calculation
Attribute Effective capacity in assignment with ICA contains the value calculated at the
end of the assignment with ICA.
The effective capacity corresponds to the link capacity on uncongested links. On congested
links, effective capacity is given by the minimum of capacity and link volume.

PTV AG

Chapter 5.16: Stochastic assignment

Link attribute that represents the difference between demand volume and volume plus
queue length. Deterred volume refers to the part of the volume that, according to blocking
back calculation, is held back upstream and so does not reach the link.
Attribute Deterred volume upstream in assignment with ICAcontains the value
calculated at the end of the assignment with ICA.

T = 1,800, i.e. T corresponds to half the assignment period [in sec]

By adapting the link VD function, you ensure that the additional impedance caused by spillback
congestion is accounted for in subordinate assignment, i.e. for route search and route choice.

5.16

Stochastic assignment
Stochastic assignment procedures assume that traffic participants in principle select the best
route, but evaluate the individual routes differently due to incomplete and different information.
In addition, in a stochastic PrT assignment the demand is distributed (see "Distribution models
in the assignment" on page 308) to the found routes as for a PuT assignment using a
distribution model (e.g. Logit, Kirchhoff, Box-Cox, Lohse or Lohse with variable beta).
In order to take the spatial similarities of the routes into account during the distribution, a
similarity measure is determined from overlapping routes (analogous to independence during
timetable-based PuT assignment) it is called the Commonality Factor (C-Logit) or the
independence of each route (according to Ben Akiva) is determined.
This results in the following sequence:
1. Route search for all traffic cells for current impedance.
2. Commonality Factor or independence calculated from overlapping of all routes of an origin/
destination pair.
3. Distribution of demand to the routes of each OD pair, taking the Commonality Factor or
independence into account.
4. Repeat from step 3 until demand for all OD pairs is in equilibrium.
5. Repeat steps 1 4 until no new routes are found or until the change in the link volumes
between two iteration steps is very small.
During the route search, the number of possible routes can be increased in that it is not just the
shortest route that is found, but a number of alternatives are found using a multiple best path
search and a variation in the link impedances.

5.16.1

Evaluation of the stochastic assignment


Compared with the equilibrium assignment, there are more routes loaded even in a poorly
loaded network in the case of the stochastic assignment, because a (small) part of the demand
is also assigned to suboptimal routes due to the distribution model. In all cases, this property
is closer to reality than the strict application of Wardrops first principle.

PTV AG

365

Chapter 5: User model PrT

5.16.2

Input and output attributes of the stochastic assignment


To execute the stochastic assignment, certain entries have to be made. The table 123 gives an
overview of which input attributes have to be maintained. After calculation, the results are
available in the output attributes and can be displayed in the list view (see User Manual, Chpt.
12.1, page 1369) or in the network editor (see User Manual, Chpt. 12.2, page 1400). The
table 124 lists the output attributes which store the results of the procedure.

Table 123: Input attributes for the stochastic assignment

366

PTV AG

Chapter 5.16: Stochastic assignment

The abbreviations represent the following:


x1

Toll PrTSys has to be inserted manually in the impedance function

(x)

Can be used optionally

(*)

Apart from the parameters which are directly set in the assignment procedure

Table 124: Output attributes for the stochastic assignment

5.16.3

Procedure of the stochastic assignment


The procedure is broken down into an external and an internal iteration (illustration 105).

PTV AG

The external (global) iteration with iterator n is used for the route search. This loop is
repeated until either n = N or until no new shortest routes are found.
The internal iteration with iterator m is used to assign the volume to the routes. This loop is
repeated until either m = M or until the deviations of the impedances on the network
elements and the deviation of the volumes on the routes between two iteration steps is very
small.

367

Chapter 5: User model PrT

Start of
external
iterartion
Search
impedance

Counter for
external
iteration

Route search

Termination
external
iteration
R oute
preselection

Independence

368

n =0

C alculate impedance R in the unloaded network for all


network elements.

n= n + 1

C alculate one route per OD pair using a shortest path


search with R n.
Generate other routes by varying R n based on a standard
distribution curve with pre-defined variance.
Option: Insert route only, if the detour test is successful,
i.e. the new route is not a trivial version of an existing
route.

N umber of new shortest routes > 0

no
stop

ja
Delete all routes with R > a R* min + b and
t0 > c t 0,min + d

C alculate independence factor (commonality factor) that


takes into account the relative similarity of the routes or
calculate the independence (Ben Akiva)

PTV AG

Chapter 5.16: Stochastic assignment

Start of internal
iteration
Initialisation of
choice
impedance

m =0

Set impedance R or R* of all network objects to


impedance in the unloaded network.

Counter for
internal
iteration

m= m +1

Calculate R * of all routes as a total R * for all traversed


network objects.
Correct impedance using impedance factor.

Choice
impedance

Assignment of demand across the routes in accordance


with Logit, Box-Cox, Kirchhoff, Lohse or Lohse with
variable beta results in route volumes q rm*

Route choice

q rm =

Route volume

Update search
impedance

q r (m1) ( m 1) + q rm '
m

Calculate R * for all network objects from the volumes that


result from the route choice.
The search impedance is an estimated R * value that is
calculated as in the Equilibrium_Lohse procedure:

*
*
Rnew
= Ro*ld + Rnew Rold

m = max. number of internal iterations or


is valid for the impedance of all network elements, and

Termination
criterion for
internal
iteration

Rm* Rm* 1 min( E1 max( R*m, R*m1 ) + E 2 , E3 )

no

is valid for the volume of all routes

q rm q r (m1) min( E4 max(q rm , q r( m1) ) + E5 , E6 )

Termination of
external
iteration

ja
n = max. number of external iteration
stop

no

yes

Illustration 105: Procedure of the stochastic assignment

The alternative route search by stochastic variation of the impedances is closely related to
other procedures used to determine k-shortest paths and shares their common drawback that
often new routes are found that differ insignificantly from previous routes. Such routes are not
desirable as they hardly change the volume situation in the network and only increase the route
quantity, which leads to extended computing time and higher memory requirements. For this
reason a detour test is offered as part of the stochastic assignment that discards a route r2 if a
route r1 already exists that matchesr2, with the exception of a subsection, and if this subsection

PTV AG

369

Chapter 5: User model PrT

in r2 is significantly longer than in r1. More precisely, r2 is discarded in favor of r1 if the following
applies (illustration 106).

r1 = AT1B

r2 = AT2B

Length(T2) > Factor Length(T1)

Illustration 106: Discarding routes

The route sections A and B can be empty if the subsection is at the start or the end of the
routes.

5.16.4

Similarity of routes and commonality factor


In the case of the stochastic assignment, alternative routes are generated - based on another
assignment as initial solution - for an OD pair by varying the impedances of the network objects
based on a distribution, in order to model the incomplete information supplied to the road-users
and their individual differences in terms of perception and preferences. In this way, it is
possible to calculate in one step not only the shortest route in terms of impedance, but also
alternative routes with higher impedances. After completion of the route search, depending on
the route impedance based on an assignment model (Logit, Box-Cox, Kirchhoff, Lohse or
Lohse with variable beta), the demand is distributed across the alternatives. The similarity of
the routes is to be taken into account during the distribution process. The problem of similarity
is illustrated with the example below (illustration 107):
Whereas the independence of the routes is given in cases 1 and 2, there is a dependence of
routes 1 and 3 in case 3, since there is some degree of overlap. This overlapping must be
taken into consideration in the route choice.

370

PTV AG

Chapter 5.16: Stochastic assignment

Case 1

Portion

Route 1

expected

Logit

Route 1

50%

50%

Route 2

50%

50%

Route 2

Impedance R1 = R2

Case 2

Portion

Route 1

expected

Logit

Route 1

33%

33%

Route 2

33%

33%

Route 3

33%

33%

Route 3

Impedance R1 = R2 = R3

Case 3

Portion

Route 2
Route 1

expected

Logit

Route 1

approx.
28%

33%

Route 2

approx.
44%

33%

Route 3

approx.
28%

33%

Route 3

Impedance R1 = R2 = R3

Route 2

Illustration 107: Example for similarity of routes

The C-Logit approach proposed by CASCETTA is a suitable way of overcoming this problem.
To do this, a so-called commonality factor C is introduced to measure the overlapping of the
two routes r and s as follows:

PTV AG

371

Chapter 5: User model PrT

t 0 rs
l rs
C rs = --------------------- or C rs = --------------t0 r t0 s
lr ls

with
Crs

Similarity of the routes r and s (Commonality factor)

t0rs

Time t0 of the common sections of the routes r and s

t0r

Time t0 of route r

lrs

Length l of the common sections of the routes r and s

lr

Length l of route r

Thus, Crs equals 1, if the two routes are identical, and will be 0, if the two routes do not overlap.
The commonality factor Crs is determined for all route combinations. Then, the correction factor
CFr of a route r compared to any other route s is defined as follows:
1 - = --------------------------------1
CF r = --------------- Crs 1 + Crs
rs

The correction factor of a route r is 1 if the commonality factors Crs for all routes s have the
value 0, i.e. the route has no overlap with another route. In any other case it is below 1. The
correction factor CFr is then regarded in the Logit model as follows:
Vr

e CFr
P = ------------------------------------------N

s = 1 ( e

Vs

CF s )

In the case of Box-Cox, Kirchhoff, Lohse or Lohse with variable beta, its inclusion is also
carried out in the same way.
Alternatively, the correction factor CFr can be determined using a simpler approach according
to Ben Akiva. It is then defined as:
CF r =

t0 a

- ---------
a P -----t 0 r N ija

or
CF r =

la

a P ---lr- --------N ija

with

372

t0a

Time t0 of link a

t0r

Time t0 of route r

la

Length l of link a

lr

Length l of route r

Nija

Number of routes of the OD pair ij that lead across link a

PTV AG

Chapter 5.16: Stochastic assignment

5.16.5

Example for the stochastic assignment


The table 125 shows the main key input data for the sample network. If the following
parameters are chosen for the search, then in a single external iteration, all 3 conceivable
routes will be found:

Number of search iterations = 5

= 8 R0.5
Compared to the "objective" impedances (resulting from impedance definitions and VDFs),
the impedances of the network objects are changed for alternative shortest path searches.
They are drawn randomly from a normal distribution which has the objective impedance R
as mean value and whose standard deviation is given as a function of R.

LinkNo

Type

v0 [km/h]

Length [m]

Capacity [car units]

R0* [min]

R0* [s]

20

100

5,000

1,200

03:00

180

20

100

5,000

1,200

03:00

180

20

100

5,000

1,200

03:00

180

20

100

5,000

1,200

03:00

180

20

100

5,000

1,200

03:00

180

20

100

5,000

1,200

03:00

180

30

80

16,000

800

12:00

720

30

80

5,000

800

03:45

225

10

40

60

10,000

500

10:00

600

11

40

60

5,000

500

05:00

300

Route

Links

Length [m]

R0* [min]

R0* [s]

1+8+9

26,000

0:18:45

1,125

1+2+3+5+6+7

30,000

0:18:00

1,080

10+11+5+6+7

30,000

0:24:00

1,440

Input parameters
BPR function with a = 1, b = 2, c = 1
Bottom = 0.5, Top = 0.5 = 0.5
Assignment with Logit, = 0.001
Table 125: Impedance in the unloaded network, input parameters for stochastic assignment

After completing the search, the correction factor for the independence of each route is
determined according to Cascetta. It is based on the similarity of the individual route pairs with
reference to time t0 or to the length. The table 126 shows the commonality factors C. From this,
the correction factor CFr of route r is calculated.

Route 1
1 - = ----------------------------------------1
CF 1 = ---------------= 0.8596
+
1.0
0.16
+ 0.0
C
1j
j

PTV AG

373

Chapter 5: User model PrT

Route 2
1 - = -------------------------------------------1
- = 0.6264
CF 2 = ---------------+
0.16
1.0
+ 0.43
C
2
j

Route 3
1 - = ----------------------------------------1
CF 3 = ---------------= 0.6978
+
0.0
0.43
+ 1.0
C3 j
j

Route pair

t0ij

t0i

t0j

Cij

1,1

1,125

1,125

1,125

1.00

1.2

180

1,125

1,080

0.16

1.3

1,125

1,440

0.00

2,1

180

1,080

1,125

0.16

2.2

1,080

1,080

1,080

1.00

2,3

540

1,080

1.440

0.43

3,1

1,440

1,125

0.00

3,2

540

1,440

1,080

0.43

3.3

1,440

1,440

1,440

1.00

Table 126: Calculation of the commonality factor C for all route pairs

The share by route is calculated from the correction factor according to Cascetta and from the
impedance Rmin0 in the unloaded network.
For Route 1, the portion is calculated using the Logit model as follows:
-0.0011125

0.8596 e
P 1 = ---------------------------------------------------------------------------------------------------------------------------------------------------------------= 0.425
-0.0011125
-0.0011080
-0.0011440
0.8596 e
+ 0.6264 e
+ 0.6978 e
In the same way, the portions showed in the table 127 result for Routes 2 and 3. The volume
of each route qr1 in the first iteration step results from the product of portion P and demand F.
For Route 1, the calculation is as follows: 0.425 2000 = 849.4 PCU. From the route volumes,
the link volumes and thus the network impedances can then be calculated (illustration 108).
This results in the impedances R1 of the routes. These interim results can be verified in Visum
if the maximum number of internal iterations are set to M = 1 in the assignment parameters.
Route

Rmin0

exp(Rmin0)E

Portion P

qr1

R1

0.8596

1,125

0.279079049

0.425

849.4

2,470

0.6264

1,080

0.212737561

0.324

647.5

1,961

0.6978

1,440

0.165335421

0.252

503.2

2,848

0.657152032

1.000

2,000.0

Total

Table 127: Volumes in the first internal iteration step m = 1

374

PTV AG

Chapter 5.16: Stochastic assignment

A Village

X City

Illustration 108: Volumes and link run times after the first internal iteration step m=1

For the route choice in the second iteration step, an estimated impedance Rmin1 is calculated.
Since = 0.5, this impedance results from the formation of the mean value of Rmin0 and R1. On
the basis of Rmin1, as in the first iteration step, the assignment is then made for the 3 routes.
For each route, the interim result is qr2. To smooth the volumes between two iteration steps,
the MSA method (Method of Successive Averages) is used.
q r ( m 1 ) ( m 1 ) + q rm'
q rm = ---------------------------------------------------------m

For m = 2, this results in the following for the volume of Route 1:


( 2 1 ) + 788.8q r 2 = 849.4
--------------------------------------------------------2

This route volume then leads to the link volumes and impedances of the second iteration step
(table 128). The iterations are repeated until the termination criteria are met.
Route

Rmin1

exp(R)E

Portion P

qr2

qr2

R2

0.8596

1797.6

0.142432

0.3944

788.8

819.1

2,405.2

0.6264

1,520.7

0.136919

0.3791

758.3

702.9

2,016.0

0.6978

2,144.0

0.081775

0.2264

452.9

478.0

2,785.6

Total

0.361126

2,000

Table 128: Volumes in the second internal iteration step m = 2

PTV AG

375

Chapter 5: User model PrT

5.17

TRIBUT
Taking road toll into consideration, a constant value of time is set in conventional procedures,
which in principle can be used to convert the costs (toll) into time and the conventional
monocriterial assignment procedures are directly applicable.
Compared to the conventional approach, TRIBUT uses a concurrent distributed time value.
Accordingly, TRIBUT calculates in the route search as well as in the route choice with two
separate criteria, namely with time and costs (bicriterion).
This method has been used for many years in France, for the evaluation of privately financed
freeways with toll management. Compared to the conventional approach, this approach is a
more realistic price elasticity when using toll roads.
Road tolls are transport system-specific and can either be defined for a link or a link sequence.
Using link sequences allows modeling of non-linear toll systems.
Road toll modeling is an add-on which basically can be used with any equilibrium assignment
procedure. Visum provides two extensions of this kind: TRIBUT-Equilibrium (as extension to
the "Equilibrium" method) and TRIBUT-Learning procedure (as extension to the
"Equilibrium_Lohse" method).

5.17.1

Input and output attributes of the TRIBUT procedure


To execute a TRIBUT procedure, certain entries must be made. The table 129 gives an
overview of which input attributes have to be maintained. After calculation, the results are
available in the output attributes and can be displayed in the list view (see User Manual, Chpt.
12.1, page 1369) or in the network editor (see User Manual, Chpt. 12.2, page 1400). The
table 130 lists the output attributes which store the results of the procedure.

376

PTV AG

Chapter 5.17: TRIBUT

Table 129: Input attributes for TRIBUT

The abbreviations represent the following:


0

PTV AG

Generally possible, however not recommended

377

Chapter 5: User model PrT

Table 130: Output attributes for TRIBUT

5.17.2

Basics of the assignment with toll consideration


The decisive feature of an assignment procedure is the impedance definition for route
evaluation and route choice. With all toll-regarding assignment procedures, the impedance Rr
of a route r consists of travel time tr and monetary costs cr:
R r = t r + c r VT

Here, VT is the value of time in [/h], for example. Though this equation applies to all tollregarding assignment procedures, the TRIBUT procedure differs from other procedures in two
properties:

Monetary route costs can be calculated in different ways.


The value of time VT is no constant value per demand segment, but VT is modeled as
stochastic parameter that varies according to a particular probability distribution.

Link toll
In the simplest case, the route's monetary costs result from summing up the toll amounts by
link along the route.
The following applies:

378

tL = t(VolL)

Travel time on a link L as a function of the volume

VolL

Volume of link L

CL

Toll value for using link L

VT

Value of time in [/h], for example

PTV AG

Chapter 5.17: TRIBUT

This toll type applies to the HGV toll in Germany, for example: On parts of the network
(highways), heavy goods vehicles have to pay a toll amount which is precisely proportional to
the covered distance. Thus to each link of the highway link type the product from the link length
x constant km cost multiplication can be allocated as toll amount. For any other link and for any
other transport system, the toll amount = 0. The total of these amounts summed up along a
route represents the cost resulting from the distance traveled on highway links for the transport
system HGV.
For link toll, no toll system has to be defined. It is not necessary either to include the link
attribute Toll-PrTSys in the impedance definition, since TRIBUT regards this amount
automatically.
Note: The TRIBUT-Equilibrium assignment always regards the link-specific toll values. The
TRIBUT-Learning procedure only regards the link-specific toll values of links which do not
belong to any toll system.

Area toll
Especially toll systems for inner city areas often use a different type. For the area toll, a
geographically coherent section of the network is stated as toll area. A distance-independent
fixed amount is charged, if a section of a route runs through the toll zone.
c
R r = t r + ------r- =
VT

c
------t
+
L r L VT
0

if a ( L r ) lies in the toll area


else

Illustration 109: Example for area toll: The London Congestion Charging Zone

PTV AG

379

Chapter 5: User model PrT

At first view, the monetary costs of a route do not depend on the individual links being
traversed, but on the route course as a whole in this case. Basically this is right, however,
TRIBUT - like any other assignment procedure - is based on shortest path searches via links
and requires the impedances by link therefore. That is why TRIBUT puts the area toll down to
the link toll case. For that, define the toll area first by creating a network object 'toll system' of
the area toll type and then allocating the toll area's number to all links which are located in the
area as value for the attribute Toll system number. The toll system additionally stores the
fixed toll amount for each transport system. For the clear definition of the figure described
below, all connector nodes of a zone need to be located either within the toll area or outside of
it.
On this basis, TRIBUT defines the toll amounts for links, turns, and connectors as follows:
cL = 0 for all links L
cC = 0 for all connectors C
c
c T = T --- for all turns T, with T = 1, if turn T leads from a link inside the toll area to a link
2

outside or vice versa, i.e. if the toll area border is crossed. Otherwise, T = 0.
c
c X = X --- for all transitions X from connectors to links, where X = 1, if the transition X leads
2

to a link in the toll area or originates from there. Otherwise, X = 0.


The illustration 110 illustrates the principle:
Zone 2

Zone 1

Link outside
of toll area
Link inside
of toll area
Turn with toll
Connector
with toll
Connector
without toll

Illustration 110: Reducing the area toll to the link toll case
(For clarity reasons, turns without toll are not displayed)

Summing up the toll amounts along a route results in an amount null for routes that do not
touch the toll area at all. Any other route (origin traffic, destination traffic, through traffic, internal
traffic of the toll area) is charged with the toll amount of c, since they traverse exactly two
network objects with toll amount = c/2 each.
In a Visum model, you can define multiple toll systems of the area toll type. Then, the
definitions for turn and connector cost are applied to each toll system with the associated fixed
toll amount. For turns between two toll areas the two toll amounts are charged.
Please note the two characteristics. For routes, that cross the border of the toll area multiple
times the toll amount is charged multiple times. This might not correspond to reality, however
it cannot be avoided for the required reduction to additive toll amounts per network object.
Furthermore, the internal traffic within the toll area can be excluded from toll calculations in

380

PTV AG

Chapter 5.17: TRIBUT

reality. For the TRIBUT route choice it is no problem that these flows are nevertheless charged
with toll amounts, since the toll comparably refers to all route alternatives and thus this additive
constant value does not modify the equilibrium solution. But when calculating a skim matrix of
the impedance for future use in a demand model for example, you need to perform an
additional matrix operation after skim matrix calculation to subtract the toll amount from the
internal traffic OD pairs data.
Note: Only the TRIBUT-Learning procedure takes the area toll into consideration.
For links that belong to a toll system the link attribute Toll-PrTSys is not regarded.

Matrix toll
Another type of toll models is often applied to arterial highways. In this case we have a
physically cohesive subnetwork with a limited number of connections (entries and exits) to the
remaining network (illustration 111).

Illustration 111: Toll station at highway exit

Toll amounts are not defined as the sum of toll amounts by link, but arbitrarily as fee by pair
(entry, exit). Using such a fee matrix, the operator has more flexibility since the 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 112:
Link outside
of toll area

3
1

Link inside
of toll area
Node
with number

Illustration 112: Example of a matrix toll

PTV AG

381

Chapter 5: User model PrT

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 131.
from / to node

Table 131: Toll amounts for the example network

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. The illustration 113 shows the graph that
is generated for the shortest path search in the example.
Link outside
of toll area

Virtual link
with road toll
Node
with number

Illustration 113: 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 cA-C cA-B + cB-C. 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.
Notes: Only the TRIBUT-Learning procedure takes the matrix toll into consideration.
For links that belong to a toll system 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 132). This description is reduced to the link toll case, since the
basic principle does not differ by toll type.

382

PTV AG

Chapter 5.17: TRIBUT

"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 cR of a route
are converted into a constant time penalty.

bicriterial
During the assignment, both criteria (tR and cR)
must always be available for each path.

Table 132: Comparison of conventional toll assignment and TRIBUT

The complexity of a bicriterial route choice procedure can be made clear in a time-cost diagram
(illustration 114).
cost
c

cA

Route A

VT = - |cB-cA|/ |tB-tA|
Route B

cB

tA

tB

time t

Illustration 114: Time-cost diagram

5.17.3

Each point on the diagram, for example A = (tA,cA), 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.

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.

( )

VT = log N vt ,

PTV AG

383

Chapter 5: User model PrT

The two distribution parameters apply:

( )

vt

Position parameter, corresponds with the Median of VT = log N vt ,

Distribution parameter
This parameter corresponds with the standard deviation of the associated standard normal variable.

( ) has the following properties:

VT = log N vt ,

The probability is equal to zero for negative values.

The position parameter vt corresponds with the Median of VT = log N vt , , which means

( )

that the distribution function adopts the value of 50 % for VT= vt .


The illustrations show the density function (illustration 115) and the distribution function
(illustration 116).

Logarithmic normal distributions

0,060
Density function g1(vot)
Density function g2(vot)
0,050

g(vot)

0,040

0,030

0,020

0,010

0,000
0

10

20

30

40

50

60

70

80

90

value of time

Illustration 115: Density function

384

PTV AG

Chapter 5.17: TRIBUT

1,200
Distribution function G1(vot)
Distribution function G2(vot)
1,000

G(vot)

0,800

0,600

0,400

0,200

0,000
0

10

20

30

40

50

60

70

80

90

value of time

Illustration 116: Distribution function

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 117).
c

D
VTcrit C/D

X
C

VTcrit B/C

VTcrit A/B

Y
A
t

Illustration 117: Path Search

PTV AG

385

Chapter 5: User model PrT

The illustration 117 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:

5.17.5

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.

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.
As illustrated in illustration 118 the demand shares of the four efficient routes can be derived
from the probability distribution of the VT.
100%
P (D)
P (C)

P (B)

50%

P (A)

VTcrit A/B VTcrit B/C

VTcrit C/D

0%

Illustration 118: 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 320), 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 119). The following steps
are carried out:

386

Balance between the route of a toll level

PTV AG

Chapter 5.17: TRIBUT

Balance between the neighboring toll levels


Constant correction of the course of the convex front and adjustment of the critical values
of time.
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

Route spl it

Route search

Determination of efficient routes for curr. time impedances


yes
Found new routes?
no
End

B
N
A

Illustration 119: 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 354). 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.

PTV AG

387

Chapter 5: User model PrT

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:

Illustration 120: Attribute selection for the Toll systems list

388

PTV AG

Chapter 5.18: Dynamic User Equilibrium (DUE)

Illustration 121: Attribute selection for the Toll matrices list

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.

PTV AG

389

Chapter 5: User model PrT

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 769).

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 122).

Illustration 122: The dynamic user equilibrium problem

390

PTV AG

Chapter 5.18: Dynamic User Equilibrium (DUE)

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 122).
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 123, has an iterative nature, since each variable has to be
recalculated until a convergence is achieved.

link flows, travel times, ad time I


link travel time temporal profiles

link flow temporal profiles

link flows, travel times, at time i

period of analysis

period of analysis

link flows, travel times, ad time i+1

link flows, travel times, at time 0

state of the network

state of the network

Illustration 123: 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 124).

PTV AG

391

Chapter 5: User model PrT

network loading
map

demand
flows

arc conditional
probabilities

implicit path enumeration


route choice model

network flow propagation


model
arc flows

arc performance
function

arc travel times

arc costs

network performance
model

Illustration 124: 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 leastcost 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
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 393). Subsequently, the network performance model and
its submodels are described (see "Network performance model" on page 397). Then, the
display of the network loading map (see "Assignment of the network demand (network
loading)" on page 406) 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 408). A
numeric example including the analysis rounds off the procedure description (see "Example of
the Dynamic user equilibrium" on page 410).

392

PTV AG

Chapter 5.18: Dynamic User Equilibrium (DUE)

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 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 a node dZ users consider the set Kod 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 N to a given destination Z. Graph G is assumed to be strongly connected, so
that Kxd with xN dZ is non-empty.
Path topology is described through the following set notation:
A(k) = concatenated sequence of arcs constituting the path kKod from oN to dZ.

The following notations are adopted for the network volumes.


Dod()

Vehicle demand, which are moving from origin oN to destination dZ and are departing at
time

fa()

Vehicle flow, which at time is traversing arc aA

Fa()

cumulated vehicle flow, which at time is traversing arc aA

ua()

Exit flow from arc aA at time

The following applies by definition:


Fa ( ) =

fa ( ) d

(27)

For the calculation of network performance, travel times are introduced through inflow-outflow
functions, and the following notation is adopted.

PTV AG

ca()

Cost of traversing arc aA for vehicles entering it at time

ta()

Outflow time of arc aA for vehicles entering it at time

fa-1()

Inflow time of arc aA for vehicles exiting it at time

Ck()

Cost of path kKod from oN to dZ for vehicles departing from node o at time

Tk()

Outflow time of path kKod from oN to dZ for vehicles departing from o at time

393

Chapter 5: User model PrT

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 Tk() 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 Ck() 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:
Tk ( ) = Th (t a ( ))

(28)

Ck ( ) = ca ( ) + Ch (ta ( ))

(29)

where a = (o, x)A is the first arc of k and hKxd is the rest of path k (illustration 125).

ta()

Tk() = Th(ta())

ca()

time

Ch(ta())

a = (o, x)A(k)

hKxd

Ck() = ca() + Ch(ta())


kKod

dZ

oN

(x, y)A(k)

y
time

Illustration 125: 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:
t a ( ' ) > t a ( ) , for all t > t

(30)

The monotonicity expressed by (30) ensures that the temporal profiles of the arc exit times are
invertible. Moreover, the FIFO rule applies also to the entrance times.
t xy 1 ( ' ) > t xy 1 ( )

394

, for all t > t

(31)

PTV AG

Chapter 5.18: Dynamic User Equilibrium (DUE)

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 126, expressing the vehicle flow qa(x,) at a given
section x of the arc and instant t, as a function of the vehicle density ka(x,) at the same section
and instant.
The arc is then characterized by:
La

Length of arc a

Qa

Capacity of the initial bottleneck and of the homogeneous channel associated with arc a, called
in-capacity;

Sa

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 Sa
Qa;

Va

Maximum speed allowed on arc a, called free flow speed in Visum

KJa

Maximum density on arc a called jam density

Wa

propagation speed of hypercritical flow states on arc a, called hypercritical kinematic wave
speed.

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 incapacity, 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 outcapacity.

Illustration 126: The adopted parabolic-trapezoidal fundamental diagram, expressing the relation among
vehicular flow, speed and density along a given arc.

In illustration 126, k2a k1a is assumed, implying the following relation among the above
parameters:

PTV AG

395

Chapter 5: User model PrT

2- -----1-
KJ a Q a ----V W
a

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, koa(q) and voa(q) express the density and the speed as functions of the flow in presence
of hypercritical flow conditions, while kua(q) and vua(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
depicted in illustration 127 may be adopted, where, in order to guarantee k2a k1a, the
following relation must apply:
1- -----1-
KJ a Q a ----V a W a
hypocritical flow conditions

hypercritical flow conditions

flow
Qa
q

kua(q)

Qa / Va

Wa

voa(q)

Va
k1a

k2a

koa(q)

KJa

density

-Qa / Wa

Illustration 127: 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 = {0, , i, , 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 gi = g(i) taken at each
instant i. This way, any temporal profile g() can be then represented numerically through
the vector g = (g0, , gi, , gn).

396

PTV AG

Chapter 5.18: Dynamic User Equilibrium (DUE)

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
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 128
in the context. The journey times which result from the solution of the three feedback model
components, are combined with the monetary costs to generalized costs by an Arc Cost
Model.
network
performance model

exit flow and travel time model


in- capacities

arc inflows
arc outflows

arc exit flows

entry capacity model


out-capacities

arc travel times

arc cost model


arc costs

arc entry capacities

exit capacity model


arc exit capacities

Illustration 128: 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.

PTV AG

397

Chapter 5: User model PrT

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 ra() can be
expressed, dependent of the previous part of the inflow time series, which corresponds to the
inflow fa() at any time .
ra ( ) = ra ( f a ( ) : )

(32)

Equation (32) is described below.

for the trapezoidal fundamental diagram (see "Hypocritical exit time model for a trapezoidal
fundamental diagram" on page 399) (illustration 127)
for the parabolic fundamental diagram (see "Hypocritical exit time model for a parabolic
fundamental diagram" on page 399) (illustration 126)

If, however, at the end of the edge there is a bottleneck with a time-varying capacity a() Sa
for each time , the time series of the cumulative outflow is determined, whose value Ea() at
time t is defined as follows.
Ea ( ) = min Fa ra 1 ( ) + a ( ) a ( ) :

(33)

where a() denotes the cumulative exit capacity at time t.


a ( ) =

a ( ) d

(34)

This means that a() - a() vehicles can exit the edge between times and .
The above expression (33) is based on the following specification of the FIFO rule, stating that
the cumulative exit time at the exit instant ta() of a vehicle that enters the arc at t is equal to
the cumulative inflow at time t. This means the following:
Ea (ta ( )) = Fa ( )

(35)

Then, equation (33) 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 (35), the cumulative
exit flow is equal to the cumulative inflow at time ra-1() when a vehicle that enters the arc at
time ra-1() 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 Ea() from the cumulative inflow at time ra-1()
plus the integral value of the exit capacity between and t, which is a() - a().
By definition, the exit flow ea() from arc a at time t is:
ea ( ) = dEa (r ) / d

(36)

By definition, ea() a() applies at any time and hypercritical exit flows occur if ea() = a().
Knowing the cumulative inflow and exit flow temporal profiles, the FIFO rule (35) yields an
implicit expression for the arc exit time temporal profile.

t a ( ) = max r a ( ), min : E a ( ) = F a ( )

398

}}

(37)

PTV AG

Chapter 5.18: Dynamic User Equilibrium (DUE)

The illustration 129 depicts a graphical interpretation of equation (37), where the time profile of
the cumulative exit flow Ea() complies with the lower envelope of the following curves:
a) the cumulative inflow Fa(), shifted forward in time by the hypocritical travel time ra() -
thus yielding the temporal profile Fa[ra-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 (,Fa[ra-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 illustration 129, the calculation of the exit time from
the cumulative time series of inflows and outflows is illustrated by thick arrows.

Illustration 129: 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 (28) is simply specified as follows.
ra ( ) = + La / Va

(38)

In this case, using (33) equation (38) can be made explicit as follows:

{ (

Ea ( ) = min Fa La / Va + a ( ) a ( ) :

(39)

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 ta(). Further below you will first find a description of the precise model.

PTV AG

399

Chapter 5: User model PrT

In cases where it might require large computational effort, it can be replaced by a simpler
model that averages traffic conditions and thus limits the number of traffic situations
encountered by vehicles on 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 412).

Illustration 130: Flow pattern given by the Simplified Theory of Kinematic Waves

Based on the STKW, vehicles change their speeds instantaneously. As depicted in


illustration 130, 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 Waij of the shockwave separating the two hypocritical flow states (fai) and (faj) is:

Wa ij =

fa j fai
= vua ( f a i ) + vua ( f a j ) Va
j
i
kua ( f a ) kua ( f a )

(40)

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 ra(). The
illustration 130 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 131, we assume that at each
instant ri, 0 i n-1, a fictitious shockwave is generated on the initial arc section separating the
actual flow state (fai+1) from a region with the average speed i = L / (rai - i) of the vehicle
that reaches the arc at time i.

400

PTV AG

Chapter 5.18: Dynamic User Equilibrium (DUE)

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 (36), the slope Wai of the fictitious shockwave is as follows:

Wa i = i + vu ( f a i +1 ) Va

(41)

average trajectory of the vehicle entering the running link at time i, , 0 i n-1
fictitious shockwaves
space

outflow profile

La

1
3

vua

vua
2

Wa
0

Wa

Wa

fa3

f
1

Wa
3 4
fa

1
2
a

fa1

Wa
4
fa5
4

inflow profile

time

Illustration 131: 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 ai = 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 Wai-1 before the end
of the arc, its hypocritical exit time is simply:

ra i = i + La vua ( f a i ) .
Here, fai is the arc inflow during time interval (i-1,i].

PTV AG

401

Chapter 5: User model PrT

b) Otherwise, its hypocritical exit time is determined on the basis of the two speeds it
assumes before and after crossing the fictitious shockwave.

ra i = i + i + ( La i vu ( f a i ) ) i 1 .
where i is the travel time of the vehicle before it reaches the fictitious shockwave
(illustration 132).

i = (i i 1 ) Wa i 1 (vu ( f a i ) Wa i 1 ) .
rai

space

rai-1

i-1

i-1

W i-1
i

i-1
L

vu(f ai)
time

Illustration 132: Determination of the arc hypocritical exit time

Then, the hypocritical travel time ra() specifying (32) is:


ra ( ) = ra i + i rai +1 rai / i +1 i , i , i +1 ,0 i n 1

(42)

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 1006). 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 126 or illustration 127 it is clear that wa = with KJa = k2a 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
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.

402

PTV AG

Chapter 5.18: Dynamic User Equilibrium (DUE)

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 ea() = a() would reach the initial section is given as
follows.

a ( ) = + La / wa (ea ( ))

(43)

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 133 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

[1 / va (q ) + 1 / wa (q )] multiplied by that flow. Therefore, integrating along the arc from the final
to the initial section, we obtain the maximum cumulative flow Ha() that would be observed at
time a() in the initial section as:

Ha() = Ea ( ) + ea ( ) La [1 / va (ea ( )) + 1 / wa (ea ( ))]

PTV AG

(44)

403

Chapter 5: User model PrT

space
kinematic wave
vehicles

ds
wa(q)

va(q)

time

ds / wa(q)

ds / va(q)

Illustration 133: 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 wa(q) = wa, the time at a() = is = - La /wa - based on (43).
Furthermore, Ha() = Ea() + La KJa results -based on (44) q/va(q) = KJa - q/wa. Therefore, the
maximum cumulative inflow Ga() that could have entered the arc at time t due to the inflow
volume is given by the following equation:
La

E ------ + L a KJ a
wa
Ga ( ) = a

L
L
if e a -----a- = a -----a-

w a
w a

(45)

else

If the cumulative inflow Fa() at time t equals or exceeds the maximum cumulative inflow Ga(),
so that spillback occurs at that instant, then the entry capacity a() is given by the derivative
dGa()/d of the latter; otherwise, it is equal to the in-capacity Qa.
Differentiating Ga() implies the following:
dGa ( ) / d = ea ( La / wa )

From ea( - La /wa), the following applies:


La

- if G a ( ) F a ( )
a ----w a
a ( ) =

else
Qa

(46)

The illustration 134 shows how, based on equation (45) 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 La / wa in time and for La KJa in value. Moreover, it points
out that, if Ga() is greater than Fa(), the queue is shorter than La and a() = Qa.
Otherwise spillback occurs and a() = a( - La /wa).

404

PTV AG

Chapter 5.18: Dynamic User Equilibrium (DUE)

La / Va
vehicles
maximum cumulative inflow Ga()
inflow Fa(), fa()
exit flow Ea(), ea()
entry capacity a()
La
KJa
La / Va

La / wa
'
flow

''

time

hypercritical exit flow


spillback

Q
a

time

Illustration 134: 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 Sa 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 Sa.

PTV AG

405

Chapter 5: User model PrT

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 fb() 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() fb() / 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:

a ( ) = min{S a ; b ( ) u a ( ) / f b ( ) : b FS (x ), f b ( ) b ( )}

(47)

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:

ca ( ) = ta( ) + ma ( )

(48)

Here, ma() 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 (29). Then the minimum cost wod() between each node oN and a
given destination dZ are determined for users departing at time t.
wod() = min{Ck(): k Kod}

(49)

It can be proved that the following dynamic version of the Bellman relation for each node oN
(illustration 135) is equivalent to problem (49).
wod() = min { Cox ( ) + wx d (tox ( )) } : x FS (o )

406

(50)

PTV AG

Chapter 5.18: Dynamic User Equilibrium (DUE)

dZ

oN
(o, x)FS(o)
xN
cox() + wxd(tox())
tox()
Illustration 135: Dynamic version of the Bellman relation

The set of Bellman relations (50) 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 oN and the destination dZ departing at time t, can then
be formulated through the following extension of the dynamic case of Wardrops first principle:

If path k Kod is used, i.e., its choice probability Pk() is positive, then its cost Ck() is equal
to the minimum cost wod(), 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:


d

Pk ( ) [ Ck ( ) w0 ( ) ] = 0

(51)

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 oN to dZ 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 Pk() of a path k Kod 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:

PTV AG

407

Chapter 5: User model PrT

P k ( ) = p ox ( ) P h ( t ox ( ) )

(52)

where (o, x) is the first arc of k and h Kxd is the rest of path k.
The dynamic Wardrop condition is satisfied when the conditional probabilities of the edges are
calculated as follows.
d

p ox ( ) [ C ox ( ) + w x ( t ox ( ) ) w o ( ) ] = 0

(53)

( o, x ) FS ( o) pox ( )

(54)

= 1

p ox ( ) 0

(55)

Equation (49) 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
Cox() plus the minimum cost wxd(tox()) to reach the destination once entered x at time is equal
to the minimum cost wod(). In x, the passage time is tox() here.
The flow foxd() of vehicles directed to destination dZ that enter the arc (o, x)A at time t is
given by the arc conditional probability poxd() multiplied by the flow exiting from node o at time
t. The latter is given, in turn, by the sum of the outflow uyod() from each arc (y, o)BS(o)
entering o, and of the demand flow Dod() from o to d. This results in the following equation:
f ox ( ) = p ox ( ) D od ( ) +
d

( y, o ) BS ( o )

u yo ( )

(56)

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 tyo-1().

u yo d ( ) = f yo d (t ) yo 1 ( ) / dt yo ( ) / d

(57)

where the weight dtyo()/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:
f ox ( ) =

5.18.6

d Z fox ( ) ;
d

u ox ( ) =

d Z uox ( )
d

(58)

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.

The deterministic case


The formulation of the implicit path enumeration yields the model depicted in illustration 136.

408

PTV AG

Chapter 5.18: Dynamic User Equilibrium (DUE)

network loading map


D

p(w, c, t)

(p, t ; D)

w(c, t)

f, u
f, u

network
performance model
E( f, )

*( f, u)

c(t)

E
E( f, )

( f, E, ; Q)
E
S

t( f, u, E)

(f, u, ; S)

arc performance function

Illustration 136: 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.

PTV AG

409

Chapter 5: User model PrT

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 ca() 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:
ca h ( ) = ca ( ) + a h [ a ( )]0.5

Applies in compact form


c h = c(c; )

(59)

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 (59), the entire time series ah() 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 Training\DUE of your Visum installation as Braess_without_spillback.ver and
Braess_with_spillback.ver.
We consider the Braess network depicted in illustration 137. 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 QAC = QAE = QED = 2,000 veh/h and QBD = QCF = QDF = 1,000 veh/h.

410

Link

La[km]

Qa [veh/h]

Va [km/h]

Wa [km/h]

1 / Ka[m]

0.4

2,000

50

15

7.0

0.6

2,000

50

15

7.0

0.6

2,000

50

15

7.0

0.4

2,000

50

15

7.0

PTV AG

Chapter 5.18: Dynamic User Equilibrium (DUE)

Link

La[km]

Qa [veh/h]

Va [km/h]

Wa [km/h]

1 / Ka[m]

0.4

2,000

50

15

7.0

0.1

4,000

50

15

3.5

The assignment period is constituted by 100 intervals of 1 minute. For the first 33 minutes of
simulation, constant demand flow from node 1 to node 5 is assumed, which equals D15 = 2,300
veh/h.

2
C

A
E

D
3
Illustration 137: Example network

The outputs of two assignment runs, one without and the other with spillback congestion, are
presented in illustration 138. 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.
DUE without spillback - inflow [veh/h]

2000

arc A
arc B

1500

arc C
arc D

1000

arc E
500
0
0

PTV AG

500

1000

1500

2000

2500

3000

3500

411

Chapter 5: User model PrT

DUE with spillback - inflow [veh/h]

2000

arc A
arc B

1500

arc C
arc D

1000

arc E
500
0
0

500

1000

1500

2000

2500

3000

DUE without spillback travel time [sec]

300

3500

turn AC

250

turn BD

200

turn CF

150

turn DE

100

turn ED

50
0
0

500

1000

1500

2000

2500

3000

DUE with spillback travel time [sec]

300

3500

arc A

250

arc B

200

arc C

150

arc D

100

arc E

50
0
0

500

1000

1500

2000

2500

3000

3500

Illustration 138: 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 133 are relevant for
DUE.

412

PTV AG

Chapter 5.18: Dynamic User Equilibrium (DUE)

Network object

Attribute

Optionally timevarying

Link

TSysSet

Length

v0 PrT

Capacity PrT

Toll_PrTSys

DueVWave

DueFunDiag

SpacePerPCU

LinkSpacePerPCU

Comment

in [veh/h]

See below for explanation


of link impedance

Out capacity PrT

in [veh/h]

Link type

vMax_PrTSys

Maximum speed per


transport system on any
link of this type

Turn

TSysSet

t0 PrT

Main turn

Zones
Connectors

Capacity PrT

TSysSet

in [veh/h]

t0 PrT

Capacity PrT

in [veh/h]

SharePrTOrig/Dest*)

Do connectors have
shares{Yes/No}

t0_TSys

Weight*)

Connector share, if
enabled for zone

Table 133: Input attributes for the DUE procedure

*) 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 397). In particular, link travel time is the sum of t0 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.

PTV AG

413

Chapter 5: User model PrT

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
speed v0 (on the free-running part) until capacity is reached. The illustration 139 illustrates how
the shape of the diagram is determined by the link attributes.
sub-critical

DUE fundamental diagram

hyper-critical
2500

CapacityPrT
-D
UE
vW
av
e

1500

v0

Flow [veh/h]

2000

1000

500

0
0

20

40

60

80

100

120

140

160

Density [veh/km]

jam density = 1000 / SpacePerPCU

Illustration 139: 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 / v0 + 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 140), speed decreases
from v0 at free flow to 0.5 v0 at capacity and the flow-density curve reaches capacity with zero
derivative. The validity condition for the attributes then becomes
Capacity PrT (2 / v0 + 1 / DueVWave) 1,000 / LinkSpacePerPCU.

All other properties are identical to the sub-critical linear case.

414

PTV AG

Chapter 5.18: Dynamic User Equilibrium (DUE)

sub-critical

DUE fundamental diagram

hyper-critical
2500

zero derivative
CapacityPrT
-D
UE
vW
av
e

1500

1000

v0
/2

v0

Flow [veh/h]

2000

500

0
0

20

40

60

80

100

120

140

160

Density [veh/km]

jam density = 1000 / SpacePerPCU


Illustration 140: 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.

PTV AG

415

Chapter 5: User model PrT

Example
80 m
g = 30 s
g = 45 s
g = 45 s

Illustration 141: Signalized intersection in reality

The signalized intersection in illustration 141, with lane capacities = 1,800 veh/h, a signal cycle
= 90 s, and green fractions should be implemented in Visum as shown at the bottom of
illustration 142. The turns approaching from the West have the following capacities:

turn 1 (1 lane allowed): Q1 = 1,800 30 / 90 = 600 veh/h

turn 2 (2 lanes allowed): Q2 = 1,800 45 / 90 + 1,800 45 / 90 = 1 veh/h

turn 3 (1 lane allowed): Q3 = 1,800 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.

Q1

Q2

Q3

links
turns

Illustration 142: Diagram of the signalized node in Visum

For the compensation of the turn capacity overestimation due to shared lanes the out capacity
PrT of the incoming link from the West can be set, by adding up the saturation flow rate and the
green ratio by lane for example:
S = 1,800 30/90 + 1,800 45/90 + 1,800 45/90 = 2,400
Note: For the PrT lane capacities and/or the link out capacity you can define time-varying
values. In this way, you can model the effects of various green time splits depending on the
time of day.

Input Demand
DUE accepts a description of time-varying demand. Like elsewhere in Visum, this description
can take two possible forms:

416

PTV AG

Chapter 5.18: Dynamic User Equilibrium (DUE)

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 different demand matrix.

If the assignment time interval including the extension exceeds one day you need to use the
calendar add-on.
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 an overview table 134 shows all relevant input attributes for DUE.

Table 134: Example of the Dynamic user equilibrium

The abbreviations represent the following:


x2
x3

Toll-PrTSys has to be inserted manually in the impedance function (part of the procedure
parameters) to have an effect
Optionally time-varying

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.

PTV AG

417

Chapter 5: User model PrT

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 v0 plus the sub-critical wait time at the bottleneck (e.g. waiting for the
next green time in the cycle).
The table 135 gives an overview of all DUE output attributes.

Table 135: Output attributes of the Dynamic user equilibrium

The abbreviations represent the following:


x1

5.18.9

Totals for assignment period and values per time interval

References to the appropriate modeling for a DUE assignment


Since incorrect network modeling might lead to dramatic effects in the dynamic user
equilibrium procedure you should be aware of the following:

418

Link capacity = Saturation flow rate. The lane-specific value has to be multiplied by the
number of the link's lanes.
Bottle-necks at nodes due to control strategies, for example, have to be modeled as turn
capacities. On the one hand, the latter allow for congestion modeling by overloaded turns,
on the other hand, the inflow in overloaded links upstream can be controlled.

PTV AG

Chapter 5.19: Dynamic stochastic assignment

5.19

The out capacity of links can be used to correct the impact of shared lanes on turn
capacities. Shared lanes are neglected when turn capacities are defined which causes an
overestimation in the sum of the capacities of the link's exit turns. If the turn capacities are
not modeled in detail, the out capacities should be defined in any case.
Zones have to be connected in the subordinate network. To avoid unwanted network inflow
effects it is even recommended to add links and thus make it possible to connect zones to
one-leg nodes.
For the assignment, time intervals of only 5 - 15 min are recommended. This also applies if
you are interested in hourly values for the analysis. In this case, different intervals can be
defined the assignment time interval and the analysis time intervals.
The assignment time interval and the time extension have to be defined appropriately, all
vehicles need to be able to reach their destinations within this time range. When the
assignment comes to an end, at least in the last interval, the volumes of all network objects
should be zero.
It is recommended to activate the option Blocking back model not until plausible results
without spill-back could be reached. Even if this option has not been checked, queue length
data is calculated and displayed, but these lengths represent vertical congestions, which
do not spill back. This data can help to identify possible network modeling deficiencies. Also
spill-backs on connectors over several time intervals identify shortcomings in network or
demand modeling which have to be corrected by the user.
We recommend to adjust the standard parameter settings for the termination conditions,
since the early termination of the assignment could return incorrect results.
With extensive models, the storage of paths is not recommended. This will reduce the
memory requirements and furthermore the run time will be improved.

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.

PTV AG

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
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.

419

Chapter 5: User model PrT

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 Ti 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.10.2, page 1055).
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 143 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.

420

PTV AG

Chapter 5.19: Dynamic stochastic assignment

C
S

0
1

S
S

S
S

S
S

S
S

Links

Time
Actual path
Travel times at departure time
Travel times on reaching specific link
Illustration 143: 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 144).

Illustration 144: Example of the network volume along a connection

PTV AG

421

Chapter 5: User model PrT

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 136
gives an overview of which input attributes have to be maintained. After calculation, the results
are available in the output attributes and can be displayed in the list view (see User Manual,
Chpt. 12.1, page 1369) or in the network editor (see User Manual, Chpt. 12.2, page 1400). The
table 137 lists the output attributes which store the results of the procedure.

Table 136: Input attributes of the dynamic stochastic assignment

422

PTV AG

Chapter 5.19: Dynamic stochastic assignment

Table 137: Output attributes of the dynamic stochastic assignment

The abbreviations represent the following:


x1
x2
x3
0
(X)
(*)

5.19.3

Totals for assignment period and values per time interval


Toll-PrTSys has to be inserted manually in the impedance function (part of the procedure
parameters) to have an effect
Optionally time-varying
Generally possible, however not recommended
Can be used optionally
Apart from the parameters which are directly set in the assignment procedure

Procedure of the dynamic stochastic assignment


The procedure in illustration 145 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.

PTV AG

423

Chapter 5: User model PrT

Start of
external
iteration
Search
impedance

Counter for
external
iteration

Connection
search

Termination of
external
iteration
Connection
preselection

Independence

Start of internal
iterartion
Initialisation of
choice
impedance

424

n=0

Calculate impedance R in unloaded network for all


network objects.

n= n + 1

For each time slice T i selected in the procedure


parameters:
Calculate one route per OD pair using a shortest path
search with Rn,Ti . Find more routes by varying Rn,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.
no
Number of new routes > 0

stop
yes

Delete all connections with R > a R*min + b and


t0 > c t0,min + d
Calculate independence factor (commonality factor) that
takes into account the relative similarity of the routes
(basis: impedances in the unloaded network) or the
independence (Ben Akiva)

m =0

Set impedance R and R* of all network objects in all time


slices to impedance in the unloaded network.

PTV AG

Chapter 5.20: NCHRP 255

Counter for
internal
iteration

m= m +1

Choice
impedance

C alculate R* of all connections as total R* for all traversed


network objects in each time slice affected. Increase
impedance using deviation from desired departure time
slice and correct using impedance factor.

Connection
choice

Assignment of demand across connections in accordance


w ith Logit, Box-Cox, Kirchhoff, Lohse or Lohse with
variable beta results in connection volumes q rm*

Route volume

U pdate search
impedance

q rm =

q r (m1) ( m 1) + q rm '
m

C alculate R* for all network objects in all time slices from


the volumes that result from the connection choice. The
search impedance is an estimated R* value that is
calculated as in the learning procedure:

*
R*new = Ro*ld + Rnew Rold

m = max. number of internal iterations or


Termination
criterion for
internal
iteration

Rm* Rm* 1 min( E1 max( Rm* , Rm* 1 ) + E2 , E3 )

no

is valid for the impedance of all network elements in all


time slices, and

q rm qr ( m1) min( E4 max(q rm, q r (m1) ) + E5 , E6 )


is valid for the volume of all connections

Termination of
external
iteration

yes
n = max. number of external iteration
stop

no

yes

Illustration 145: 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.

PTV AG

425

Chapter 5: User model 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 userdefined value ranges of the calculated attribute.
The quality of the correlation can be determined and issued in two ways:

426

in groups (for each value of the classification attribute)

PTV AG

Chapter 5.21: Assignment analysis PrT

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.
Note: An assignment result is no longer necessary in order to calculate the correlation
coefficient.
The table 138 shows the calculation rules for the output attributes of the assignment analysis.
To the formulas applies:
Z
U
N

Observed value (counts or measures)


Calculated value (assignment or network model)
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

( ) = (Z i U i )2
i =1

N1 2

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)

GEH (i ) =

(Z i U i )2
(Z i + U i ) 2

ShareAccRelErr
Percentage objects within tolerance
Percent with avg rel error abs ( Z U )
i
i

------------------------------ Tolerance ( U )
Ui

NumObs
Number of observations

Number of observations per class (objects with observed value > 0)

NumClass
Number of objects in
class

Total number (=observed + not observed) objects per class

ClassVal

Value of classification attribute (or blank, if not classified)

Table 138: Calculation rules for the output attributes of the assignment analysis

PTV AG

427

Chapter 5: User model 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.

AvgAbsErr

Mean absolute error


Mean deviation of absolute values (a)
(Difference between observed and modeled values)

( a ) =

1
Abs(Zi U i )
N

AvgObs

1
Mean observed value N

AvgRelErr

Zi

Mean relative error


Mean deviation of absolute values in % (p) according to

( p ) = Abs(ZZi U i )

R2

Coefficient of determination r2
Cf. Excel function RSQ

RelRMSE

Relative root of mean square deviation

(Z i U i )2
Zi

(N 1)

StdDev

Standard deviation

Slope

Coefficient a in linear regression


Cf. Excel function: Linear Regression (y = ax + b)

Table 138: Calculation rules for the output attributes of the assignment analysis

428

PTV AG

User model PuT


The PuT user model calculates the effect of PuT supply on PuT passengers.

Subjects

6.1

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

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.

PTV AG

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 450). 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 453).
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 477).

429

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 timetablebased assignment it is treated as in the transport system-based procedure (best path search,
see illustration 146).

PuT w/o timetable

S
PuT with timetable

Illustration 146: 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 PuT-Aux 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.

430

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.

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 147,
illustration 148, illustration 149, table 139 and table 140). Find the connections between AVillage and X-City on the basis of the example's 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 139 contains example data of the PuT.dmd file which is provided in English.

PTV AG

431

Chapter 6: User model PuT

$VISION
* VisumInst
* 04/11/07
*
* Table: VERSION
$VERSION:VERSNR;FILETYPE;LANGUAGE;UNIT
4,000;Demand;ENG;KM
* Table: ODMATRIX
$ODMATRIX:NO;CODE;NAME;CONTENT;ROUND;NUMDECPLACES
1;C;Car;;0;0
2;H;HVeh;;0;0
3;P;PuT;;0;0
* Table: MATRIXSINGLELISTITEM
$MATRIXSINGLELISTITEM:MATRIXNO;FROMZONENO;TOZONENO;VALUE
1;100;200;2000.000
2;100;200;200.000
3;100;200;90.000
* Table: TIMESERIESDOMAINTYPE
$TIMESERIESDOMAINTYPE:NO;DESCRIPTION;UNITYSTRING;NUMDECPLACES;MAXVALUE;MINVA
LUE
1;Time series by percentages;%;2;9999999999.000;0.000
2;Time series of matrix numbers;No;0;999999999.000;0.000
* Table: Time series
$TIMESERIES:NO;NAME;TYPENO;UNITX;NUMINTERVALS;LENGTHINTERVAL;USEVALUELIST;VA
LUELISTTYPE; VALUEREFTYPE;DECSEPARATOR;VALUESEPARATOR
1;;1;;86400;1;0;0;2;;
* Table: Time series items
$TIMESERIESITEM:TIMESERIESNO;STARTINTERVALINDEX;ENDINTERVALINDEX;VALUE
1;1;19800;0.000
1;19801;23400;33.000
1;23401;27000;67.000
* Table: Demand time series
$DEMANDTIMESERIES:NO;CODE;NAME;TIMESERIESNO
1;;;1
* Table: Demand descriptions
$DEMANDDESCRIPTION:DSEGCODE;DEMANDTIMESERIESNO;MATRIXNO;STARTDAYINDEX;STARTT
IME
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 139: Demand matrix and temporal distribution of demand for the example

The example network is saved to the directory ...Users\Public\Public documents\PTV


Vision\PTV Visum 13\Example_net.

432

Version file: Example.ver


Graphic parameters PuT.gpa
Demand matrix and demand distribution PuT.dmd
Procedure parameters PuT.par

PTV AG

Chapter 6.2: Example network for the PuT assignment procedures

6.00

Bus 1

6.30

Train
Bus 1

7.00
Train
Bus 1
7.30
Train
8.00

A-Village
Origin

Station

B-Village

X-City
Destination

Illustration 147: Timetable


A-Village (Origin)

Station

X-City (destination)
Train

Bus 1

B-Village

Illustration 148: Line map


Timetable Bus 1
A Village

06:10 a.m.

Timetable Train
06:55 a.m.

07:25 a.m.

Station

06:25 a.m.

07:05 a.m.

07:45 a.m.

X City

06:41 a.m.

07:21 a.m.

08:01 a.m.

Station

06:22 a.m.

07:07 a.m.

07:37 a.m.

B Village

06:42 a.m.

07:27 a.m.

07:57 a.m.

X City

06:55 a.m.

07:40 a.m.

08:10 a.m.

Connections

Departure 6:10 a.m., arrival 6:55 a.m., ride time 45 min., 0 transfer
Departure 6:10 a.m., arrival 6:41 a.m., ride time 31 min., 1 transfer
Departure 6:55 a.m., arrival 7:40 a.m., ride time 45 min., 0 transfer
Departure 7:25 a.m., arrival 8:10 a.m., ride time 45 min., 0 transfer
Departure 7:25 a.m., arrival 8:01 a.m., ride time 36 min., 1 transfer
Table 140: PuT supply of the example with connections from A-Village to X-City

PTV AG

433

Chapter 6: User model PuT

6.3

PuT paths
Paths are the central result of an assignment (see "Paths in PrT and PuT" on page 209). In the
timetable-based assignment (see "Timetable-based assignment" on page 477) 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 vehicle journey
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 vehicle journeys is known, the path has a time reference (see
"Network objects of the line hierarchy" on page 58). 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 1072), these connections become visible in the PuT path leg list.
Alternatively, a path can be described without specifying vehicle journeys 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 58). 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 vehicle journey 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 1072), 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 1072)
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 453) 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.

434

PTV AG

Chapter 6.3: PuT paths

The table 141 shows the path legs which result from a timetable-based assignment in example
Example.ver. In this case, the paths were saved as connections.
Origin Destination Path
zone zone
index
100

200

Path leg
index

Passenger From stop To stop


trips
point
point
25,000

10

100

200

200

200

6:10:00
a.m.

10

OrigConn

6:10:00
a.m.

10

20

BUS1 1_H > 1

06:10:00
a.m.

20

20

Transfer

06:22:00
a.m.

20

40

TRAIN 1_H > 1 06:25:00


a.m.

40

14,000

10

10

40

18,000

10

100

40

Departure

100

Time profile ID

10

40

16,000

10

DestConn
40

06:41:00
a.m.
06:10:00
a.m.

10

OrigConn

06:10:00
a.m.

40

BUS1 1_H > 1

06:10:00
a.m.

DestConn

06:55:00
a.m.

40

06:55:00
a.m.

10

OrigConn

06:55:00
a.m.

40

BUS1 1_H > 1

06:55:00
a.m.

DestConn

07:40:00
a.m.

40

07:25:00
a.m.

10

OrigConn

07:25:00
a.m.

10

20

BUS1 1_H > 1

07:25:00
a.m.

20

20

Transfer

07:37:00
a.m.

20

40

TRAIN 1_H > 1 07:45:00


a.m.

Table 141: Path legs after a timetable-based assignment (paths saved as connections)

PTV AG

435

Chapter 6: User model PuT

Origin Destination Path


zone zone
index

Path leg
index

Passenger From stop To stop


trips
point
point

5
100

200

40
17,000

10

1
2

10

40

Time profile ID

Departure

DestConn

08:01:00
a.m.

40

07:25:00
a.m.

10

OrigConn

07:25:00
a.m.

40

BUS1 1_H > 1

07:25:00
a.m.

DestConn

08:10:00
a.m.

Table 141: Path legs after a timetable-based assignment (paths saved as connections)

For the same assignment, table 142 shows the path legs, if the paths were saved as routes.
Origin Destination Path
zone zone
index
100

200

Path leg
index

Passenger From stop To stop


trips
point
point
25,000

10

100

200

200

40

Departure
00:00:00
a.m.

10

OrigConn

00:00:00
a.m.

10

20

BUS1 1_H > 1

00:00:00
a.m.

20

20

Transfer

00:12:00
a.m.

20

40

TRAIN 1_H > 1 00:15:00


a.m.

40

49,000

10

100

Time profile ID

10

40

16,000
1

10

DestConn
40

00:31:00
a.m.
00:00:00
a.m.

10

OrigConn

00:00:00
a.m.

40

BUS1 1_H > 1

00:00:00
a.m.

DestConn

00:45:00
a.m.

40
10

00:00:00
a.m.
OrigConn

00:00:00
a.m.

Table 142: Path legs after a timetable-based assignment (paths saved as routes)

436

PTV AG

Chapter 6.4: PuT skims

Origin Destination Path


zone zone
index

Path leg
index

Passenger From stop To stop


trips
point
point

Time profile ID

Departure

10

20

BUS1 1_H > 1

00:00:00
a.m.

20

20

Transfer

00:12:00
a.m.

20

40

TRAIN 1_H > 1 00:20:00


a.m.

40

DestConn

00:36:00
a.m.

Table 142: Path legs after a timetable-based assignment (paths saved as routes)

6.4

PuT skims
By means of the Calculate PuT skim matrix procedure or during an assignment (see User
Manual, Chpt. 6.4, page 1142) the skim data can be calculated for the PuT skims of the various
skim categories (see "PuT skim categories" on page 437).
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.
2.
3.
4.
5.
6.

Skims of time (see "Skims of time" on page 437)


Skims of length (see "Skims of length" on page 439)
Monetary skims (see "Monetary skims" on page 439)
Frequency skims (see "Skims of frequency" on page 440)
Skims of attribute data (see "Skims of attribute data" on page 440)
Derived skims (see "Derived skims" on page 440)

6.4.1.1

Skims of time

In Visum, skims of time (table 143) are administered in seconds. 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

Table 143: Skims of time

PTV AG

437

Chapter 6: User model PuT

Skim

Definition

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 439).
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
assignment" on page 439).

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 Time spent inside PuT vehicles of a certain public transport system.
(IVTT)
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 439).

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 439).

Perceived journey time Perceived journey time (see "Perceived journey time" on page 446)
(PJT)
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.

Table 143: Skims of time

438

PTV AG

Chapter 6.4: PuT skims

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. The table 144 shows all skims of the length provided in Visum. The abbreviations in
parentheses indicate the file extensions which are used by default for skim matrix output in
version files.
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

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

Table 144: Skims of length

6.4.1.3

Monetary skims

The table 145 shows the monetary skims available in Visum.


Skim

Definition

Fare (FAR)

Fare for the PuT ride between origin and destination zone (see "Fares" on
page 447)

Table 145: Monetary skims [Currency units]

PTV AG

439

Chapter 6: User model PuT

6.4.1.4

Skims of frequency

The table 146 shows the available frequency skims.


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.
To the headway-based assignment, the following applies: On the graph of all
determined routes, a flow problem is solved. 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 146: Skims of frequency

6.4.1.5

Skims of attribute data

The table 147 lists the provided skim that results from the values of the selected attribute.
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 147: Skims of attribute data

6.4.1.6

Derived skims

Derived skims (table 148) result from a combination of the above listed skims.
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] / 1,000) / journey time [min] /
60)
Table 148: Derived skims

440

PTV AG

Chapter 6.4: PuT skims

Skim

Definition

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] / 1,000) / 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 userdefined 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.

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.

pt (c ) =

ut (c )
ut (c)

cC

The denominator Ut is the overall utility of the time interval.


Compared to skims representing a mean value, Ut improves with every new
connection that is added to the current transport supply.
For that reason the averaged Ut calculated over all time intervals is accounted
for as a separate skim.

U t dt
U = tT
dt
tT
Here, dt is the total demand within time interval t.

Table 148: Derived skims

PTV AG

441

Chapter 6: User model PuT

Skim

Definition

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 vehicle journey 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.

P
A a B
S
a
E (C ) = Fa e
aC
Here
a = Index over all vehicle journey items of a PuT path C
Fa = Journey time of the vehicle journey item a (known from its time profile)

Pa = Number of passengers on vehicle journey item a (over all paths,


determined by assignment)
Sa = Number of seats on vehicle journey item a (based on the total of the seats
of all vehicle journey sections which traverse the vehicle journey item on the
respective calendar day)
A,B = free parameters
Path legs covered by a TSys of the PuT-Walk or PuT-Aux type in the PuT path
are ignored.
Note
The discomfort due to capacity overload is only calculated with a timetablebased assignment.
Table 148: Derived skims

6.4.1.7

Examples for skims

The illustration 149 and the table 149 illustrate a few skims for the connections of an OD pair.
A-Village
Bus 1

Station
X-City
Train

Bus 1

Illustration 149: Example network


Connection 1

Connection 2

Used sequence of lines / route

Bus1

Bus1, Train

Access distance [m]

300

300

Access time [min]

Table 149: Example of the connection skims of an OD pair

442

PTV AG

Chapter 6.4: PuT skims

Connection 1

Connection 2

Run time [min]

45

Transfer wait time [min]


Egress distance [m]
Egress time [min]
Ride time [min]
Journey time [min]

28

500

500

45

36

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 [-]

Table 149: Example of the connection skims of an OD pair

6.4.1.8

Availability of the skims in the PuT assignment procedures

The table 150 shows which skims can be calculated per PuT assignment procedure.
Skim output by procedure

Default ext.

TSysbased

HWaybased

Timetablebased

JRT

IVT

PuT-Aux time

AXT

Origin wait time

OWT

Journey time
Journey time adapted
Ride time
Ride time adapted
In-vehicle time

JRTA
RIT

RITA

Origin wait time adapted

OWTA

Weighted origin wait time

WOWT

TWT

Transfer wait time


Transfer wait time adapted

TWTA

Weighted transfer wait time

WTWT

Extended transfer wait time

XTWT

X
X

X
X

Walk time

WKT

Access time

ACT

Egress time

EGT

Perceived journey time

PJT

Number of transfers

NTR

Table 150: Availability of the skims in the PuT assignment procedures

PTV AG

443

Chapter 6: User model PuT

Skim output by procedure

Default ext.

TSysbased

HWaybased

Timetablebased

Service frequency

SFQ

Direct distance

DID

Journey distance

JRD

Ride distance

RID

Trip distance

IVD

PuTAux distance

AXD

Walk distance (transfer walk links)

WKD

Access distance

ACD

Egress distance

EGD

Journey speed

JRS

Direct distance speed

DIS

Fare

FAR

Number of fare zones

NFZ

Number of operator changes

NOC

X
X

In-vehicle distance per TSys

IVTD

In-vehicle distance percentage per TSys

IVTP

In-vehicle time per TSys

IVTT

Impedance

IPD

Utility

UTL

Path leg attribute

PLA

Adaptation time

ADT

Extended adaptation time

XADT

Extended impedance (XIMP)

XIMP

Equivalent journey time (user-defined)


Discomfort due to capacity overload (only
calculated during assignment)

EJT

X
X

DISC

X
X

Table 150: Availability of the skims in the PuT assignment procedures

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 151):

444

PTV AG

Chapter 6.4: PuT skims

Aggregation functions

HWaybased

TTbased

Unweighted quantile
For 0 z 1 the z-quantile of a finite, classified series of values (x1, ..., xn) is
defined as smallest number y, to which applies that # is {i : xi y } / n z.

Weighted quantile
The connections are weighted with the volume at the calculation of the quantile.

Unweighted mean

Num Conn
Skimi
=1
i
mSkim =
Number of Connections
Weighted mean

NumConn
Skimi Passengersi
i
=1
mSkim =
Passengers
Unweighted mean restricted to paths of sufficiently low impedance

Skim j

mSkim =

j =1

Weighted mean restricted to paths of sufficiently low impedance

Share of

mSkim =

j =1

total demand j Skim j

Share of

j =1

total demand j

mSkim = skim value for route with minimum impedance

mSkim = skim value for route/connection with minimum perceived journey time

X
X

Table 151: Combination of skim data to the mean skim value per OD pair

Note: For calculation of a weighted mean, by default, the weights of skim matrix calculation
are used. In this case, the demand in the time series intervals is set in relation to the total
demand in the assignment period. If the weights of a percentage time series or the demand
of a matrix time series for an OD relation equals 0, a fixed demand is assumed and the
respective time interval is weighted with its length in relation to the assignment period.
The skim service frequency SFQ does not refer to a particular route or connection, but to an
OD pair.

PTV AG

445

Chapter 6: User model PuT

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:
Connection

Volume

50 %

20 %

30 %

Number of transfers

By means of the different aggregation functions, the number of transfers by OD pair is


calculated as follows:
Mean value

6.4.2

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

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 FacWT
+ Origin wait time FacOWT
+ Transfer wait time FacTWT
+ Number of transfers FacNTR
+ 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.

446

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:
Number of operator changes can be taken into account
PuT-Aux time can be weighted with a TSys attribute

PTV AG

Chapter 6.4: PuT skims

6.4.3

extended impedance can be defined


Moreover, for each component a Lambda value can be entered and/or the option BoxCox transformation can be activated.

Fares
Visum can be used to calculate fares (see "PuT fare model" on page 582). 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. Except for the
impedance definitions of both the headway-based and the timetable-based assignment
procedures, the fares can also be output as skim matrix and can be taken into account 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 448).
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.
The timetable-based method includes the temporal utility in the impedance definition in
different ways either by using a function N = f(DT) or by using T directly. In either case,
parameters are provided for the sensitiveness to early or late departures definition.
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.
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

6:00

7:00

8:00

9:00

Dep. 7:20

Table 152: Example for the determination of the time difference T

PTV AG

447

Chapter 6: User model PuT

6.5

PuT impedance functions


Like PrT assignment procedures (see "Impedance and VD functions" on page 216) the PuT
assignment procedures derive the impedance of a connection from several skims of this
connection or route (see "PuT skims" on page 437). 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 447) at the connection choice of the timetable-based
procedure (see "Timetable-based assignment" on page 477), 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 153. All factors can be set freely and also be set to
zero, so that they are not considered in the assignment.
Procedure

Definition of impedance

Timetable-based IMP = JRT Fac1 + NTR Fac2 + TSysIMP Fac3


Branch&Bound
Search
Timetable-based IMP = JRT
Shortest path
search
Timetable-based IMP = PJT Fac1 + Fare Fac2 + Tearly Fac3 + Tlate Fac4
Choice
Headway-based
Search
Headway-based
Choice

IMP = IVT + TWT Fac1 + NTR Fac2


Here, TWT represents the expected wait time for the line the passenger wants to
board for the transfer.

IMP = PJT Fac1 + Number of fare points or fare Fac2

Table 153: Comparison of the impedance functions in the PuT assignments

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 to PuT connectors either arbitrarily or by percentage (see "Distribution of
demand of a zone to the connectors" on page 47). Contrary to PrT, PuT does not provide two
variants for the proportional distribution but always uses the model "Each single OD pair
(MPA)". For PuT, the distribution by percentage may be used, for example, to assign the
transport demand to all stops which are located within a community (modeled as one zone).

448

PTV AG

Chapter 6.7: Allocation of skims with reference to lines/links

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. During the assignment, a
temporary virtual zone is generated for each connected node. The virtual zone's total demand
complies with the connector's original share in the total demand of the original zone. The
assignment calculation is based on the virtual zones. After the assignment, the temporary
zones are deleted and the results are allocated to the original zones.

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 154.
Connector node

Weight (origin)

Weight (destination)

20

30

80

50

20

40

90

60

10

Table 154: Connector weights for the example

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 155.
Virtual zone

180

20

270

30

450

50

160

40

240

60

Table 155: Temporary demand matrix for the assignment in the example

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 vehicle journeys extend from stop point to stop
point, only certain sections of links may be traversed by line routes or vehicle journeys.

PTV AG

449

Chapter 6: User model PuT

In most cases, proportional allocation of these indicator values to the link does not make
sense, which is why the definition for those indicators 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 indicators 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 indicator 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 indicator value for the (entire) link.
The illustration 150 shows an indicator value calculation example for such partially traversed
links.
Node

Stop point
A

Links

C
2

D
3

E
4

Line route 1
Service trip 1

Illustration 150: Example for indicator 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.
450

PTV AG

Chapter 6.8: Transport system-based assignment

6.8.1

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.

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 431), 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 AVillage to X-City are assigned onto this route.
This results in the volumes shown in illustration 151.

PTV AG

451

Chapter 6: User model PuT

A-Village

90

Station

X-City

90

B-Village

Illustration 151: Network volume after transport system-based assignment (parameters file TSys1.par)

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 152).
A-Village

90

Train

X-City

90

B-Village

90

Illustration 152: 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.

452

Run times of traversed links


Transfer penalty for every transport system transfer
Node type-specific or stop-specific transfer penalties

PTV AG

Chapter 6.9: Headway-based assignment

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
objects of the line hierarchy" on page 58). In the following sections the term line is used for the
sake of convenience. This emphasizes that the timetable of the individual vehicle journeys 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 475). 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 454)
2. Route search and route choice (see "Route search" on page 471 and "Route choice" on
page 472)
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 434), 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:

PTV AG

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 474).

453

Chapter 6: User model PuT

6.9.2

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
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.
Using the headway-based procedure, the fares can be regarded in the impedance
calculation. For that purpose, the full range of the Visum fare model is provided. Due to the
complexity of the fare model, taking fares into account in an assignment might increase the
required computation time. With less complex fare structures, the variant using fare points
should be favored. Note that the fare is not computed for the complete path but per path leg
during an assignment (see "Generalized costs as impedance" on page 456)).

Headway calculation
You can define the headway of a line in three different ways (see User Manual, Chpt. 6.2.3.1,
page 1085).

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.
a, b
a
= b
----------n

454

PTV AG

Chapter 6.9: Headway-based assignment

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 sensitive to shiftings of individual departures across the
interval limits. This will cause discontinuities in the result. This problem always occurs if the real
headway of a PT line is no 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 156).
Departure times

Trips in the time interval

Calculated headway

5:55, 6:35, 7:15, ...

60 minutes

6:05, 6:45, 7:25, ...

30 minutes

Table 156: Example for headway calculation from mean headway according to timetable

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.

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).
Fl = {x1, x2, ..., xn} 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 = x1 + (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 xn+1 = min{x,x} is used.

The headway is then defined as follows.


n
1
a, b

= ------------

ba i=0 i

Here applies: 0 = ( x 1 a ) , i = ( x i + 1 x i )

and n = ( x n + 1 x n ) ( x n + 1 b )

to the

remaining {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,07:00), you get a much more balanced picture.
Departure times

Trips in the time interval

Calculated headway

5:55, 6:35, 7:15

43 20

6:05, 6:45, 7:25, ...

33 20

Table 157: Example for headway calculation from mean wait time according to timetable

Using the example in the first row, the calculation can be briefly explained as follows.
In this case n = 1, x1 = 06:35 AM and x2 = 07:15 AM apply.

PTV AG

455

Chapter 6: User model PuT

Therefore follows
2

0 = ( 6:35 6:00 ) = 1225

and

1 = ( 7:15 6:35 ) ( 7:15 7:00 ) = 1600 225 = 1375

Overall this results in

6.00, 7.00

= 2600
------------- = 43,3 minutes.
60

a, b
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 471 and "Route choice" on
page 472), paths are assessed by their impedance or generalized costs respectively (see
"PuT impedance functions" on page 448). They include a perceived journey time PJT and a
fare-based component (fare or share of fare points).
IMP = PJT FacPJT + NumberFarePoints or Fare FacFare

Perceived journey time (PJT)


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
+ PuT-Aux time FacAXT
+ Access time FacACT
+ Egress time FacEGT
+ Transfer walk time FacWT

+ Origin wait time FacOWT (here, the origin wait time is computed according to a formula)
+ Transfer wait time FacTWT weight attribute of the stop area
+ Number of transfers FacNTR
+ Boarding penalty PuT (time profile attribute)
+ Boarding penalty PuT-Aux (transport system attribute)
+ Mean delay (time profile item attribute)
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 474) - in a random way on the transfer
lines' relative position to each other.
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 1091).

456

PTV AG

Chapter 6.9: Headway-based assignment

Wait time factors and penalties on the origin wait time from any attribute of stop areas and/
or time profiles
The wait time factor for the transfer wait time from any stop area attribute
A boarding penalty of any time profile attribute (for PuT lines) or transport system attribute
(for transport systems of the PuT-Aux type)
A mean delay from any time profile item 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 and penalties you can model that the passengers prefer waiting at
some stops than others.
Via the origin wait time in combination with time profile-based weighting factors you can model
that passengers do not randomly arrive at the stop but have a profound knowledge of the
timetable in the case of long mean headways. In other words, you can restrict the origin wait
time to the maximum value X via the weighting factor, for example: For all time profiles with
headway T > X, enter X / T as the origin wait time weighting factor. In this case, the weighting
factor 1 will be used for the time profiles with headway T < X.
Using PuT-Aux transport systems means no wait times, since the permanent availability of
PuT-Aux TSys is assumed. Using boarding penalties for transport systems of the type PuTAux, you can still model a delay during transition.

Number of fare points


The Number of fare points is the total of all fare points that are traversed along the route. Fare
points can be defined either for a time profile or by transport system for a link. For time profiles,
four attributes are provided: Fare points per time profile item, fare points for boarding, for
passing through, and for alighting at a stop.

Fare
As an alternative to fare points, the fare derived from the Visum fare model can also be used.
There are no restrictions applicable in terms of number or properties of the fare systems or
ticket types.
In contrast to the timetable-based variant, which includes the fare of the complete path as
impedance component in the choice model, the impedance of the headway-based assignment
includes the total of the fares by path leg. To reach precise correspondence to the real fare
model, the property Fare applies to = each path leg separately is required for each of the
used fare systems, i.e. each boarding passenger has to purchase a new ticket. In other cases,
in particular for degressive fares over several path legs, the fare total included in the
impedance can differ from the fare per total path.
The example below illustrates how fares are applied in the headway-based procedure.
The demand from A to B is 100 trips. The supply-side provides two alternative bus
connections. The model consists of 5 fare zones, and for the tickets, a zone-based fare has
been chosen as fare structure. The table lists the fares depending on the number of traversed
fare zones.

PTV AG

457

Chapter 6: User model PuT

Fare zones

Fare [CU]

>2

10

Example 1
Either line runs through from A to B, one in the North and one in the South. Either line runs
regular services every 10 minutes. The North line traverses two fare zones, the fare in the
impedance function is 5 CU. The South line traverses five fare zones, the fare is 10 CU. With
an impedance definition of 1 journey time + 2 journey time, the volumes of the south and
north lines are the same.
North

South

Journey time [min]

20

10

Fare zones (-)

Ticket fare (CU)

10

IMP = 1 Origin wait time+1 Journey


time+ 2 Fare

randomly in [0,10]+1 20+2 5


= randomly in [30,40]

randomly in [0,10]+1 10+2


10 = randomly in [30,40]

Volume

50

50

Note: For the description of the volume distribution process in the headway-based
assignment please refer to the particular section in this manual (see "Example for the
transport system-based assignment" on page 471). Since both the headways and fixed
impedance components of either route are identical, identical volumes are calculated.
Example 2
Now, the North variant consists of two separate lines providing coordinated connections with a
journey time of 10 minutes each. Neither transition times nor transfer penalties are regarded.

458

PTV AG

Chapter 6.9: Headway-based assignment

As the headway-based procedure's impedance calculation calculates the fares by path leg, a
different impedance will be returned compared to the case mentioned above: For the first
section, the fare is 5 CU (2 fare zones), for the second section, the fare is 3 CU (1 fare zone),
thus the fare sums up to 8 CU in the impedance calculation. The volume distribution changes
accordingly:
North

South

JT [min]

20

10

Fare zones (-)

Ticket fare (CU)

5+3 = 8

10

IMP = 1*Origin wait time+1*Journey


time+2*Fare

randomly in [0,10]+1 20+2 8


= randomly in [36,46]

randomly in [0,10]+1 10+2


10 = randomly in [30,40]

Volume

92

Remarks on the volume distribution: In the impedance range between 30 and 36, the South
x 36
variant accounts for all shares. In the range between 36 and 40, the probability is 1 --------------- .
10

6
4
For the South variant, the resulting probability is ------ 1 + ------ 0,8 = 0,92 .
10
10
Summing up the path leg fares in the impedance of example 2 corresponds to the situation,
where a ticket has to be bought on each path leg. If a different fare system applied in reality
(because the passenger has the right to use just a single ticket for the trip from origin to
destination, for example), an inaccuracy turns out here. For compensation purposes, "transfer
discounts" can be defined: Use the Transfer fares function which is provided with the Visum
fare model for the definition of discounts that balance the fare amount charged too much in the
case of fare system transfers. To correct the fare taking effect in the impedance formula, the
following transfer fare had to be defined in this example: 5 CU - 8 CU = -3 CU.
Note: The only difference is how fares in the impedance function are taken into account.
Finally, always the real fare is regarded, which is not the path leg fare total. This is particularly
applicable to list outputs and skim calculations. In other words, for assignment analyses the
real fare is returned by passenger trip.
Taking fares into account might significantly increase the computation time required for the
assignment, it actually depends on the complexity of the fare model. Instead of using a fare
model which mainly consists of proportional (e.g. distance-based) fares the usage of fare
points is recommended.

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:

PTV AG

No information and exponentially distributed headways


No information and constant headways

459

Chapter 6: User model PuT

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.

Notation
L = {1, ..., n} describes the set of available PuT lines. Each line i L has a certain remaining

1- of the line is derived from the


journey time si 0 and a headway hi > 0. The frequency i = --hi
latter. 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 s1 s2
... sn. The set of the first i lines is coded as follows: Li = {1, ..., i}.
Note, that the remaining journey time si 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 si < sj applies
for the remaining journey times. From sorting the times it can be deducted that i* exists, as a
consequence L* = Li*.
The wait time which applies when choosing any set L before boarding, is designated as WL.
The respective remaining costs are given as follows.

C L' = W L' +

i L'

i si

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(CL*) E(CL) 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.

460

PTV AG

Chapter 6.9: Headway-based assignment

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.
The optimal set under these model assumptions is composed as follows. The following is set
first:
i

1+
j sj
j=1
u i = ----------------------------------i

j = 1 j

Then, the optimal set of lines is achieved by L* = Li*, where i* = max{i:si ui-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 Li-1 =
{1, ..., i-1}. This procedure has the effect, that comparatively few lines are used, because with
this comparison the lines Li-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 =

i1

j = 1 j .

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.

i
i = ---------------------
j

j L
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.

1 E ( W L ) = --------------------- j
j L

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.

PTV AG

461

Chapter 6: User model PuT

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* = Li* 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 (L1, L2, ..., Ln) of
potentially optimal line sets and to cancel exactly at that point when for the first time the
following applies: ECLi > ECLi-1. This is caused by the fact, that there can be more than one
local minimum in the sequence (Li). Therefore i = argmin i { EC L } guarantees, that the
i

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.
h

i = i

( 1 j w ) dw

0 j L, j i
h = min { h i } is the minimal occurring headway. This results in the following expected wait

time.
h

E ( W L ) =

j = 1 ( 1 wj ) dw

0
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 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.

462

PTV AG

Chapter 6.9: Headway-based assignment

Given are i* n and an orderly sequence of times 0 ti* ... tl. This means that the in time
interval Ij = (tj+1,tj] just Lj = {1, ..., j} forms the optimal line set. tj is here the exact point in time
t, from which onward the remaining journey time of line j is greater than or equal to the
expected remaining costs (including wait time according to t) of the lines Lj-1. In other words, tj
is the unique solution for t in s j = E ( C L

j1

W > t) t .

The optimal strategy is as follows. If the passenger observes an arrival of a line from Ij, after
wait time Lj, 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.
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 tj mentioned above are exactly those moments when a line j is no
longer included in the optimal line set L* for this reason.

Example
Let us regard the following simple situation of two lines.
Line

Run time

Headway

10

15

13

15

Table 158: Considering elapsed wait time

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 t2 = 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.

PTV AG

463

Chapter 6: User model PuT

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 wi are known, the passenger's decision
is not subject to stochastic influences. He or she rather selects exactly that line whose
remaining costs si + wi are at a minimum.
The optimal line set thus consists of all lines, which have the least costs in some timetable
positions.

i = max { i : s i < min j { s j + h j } }

and

L = L i

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.

i = P ( C i < C j j )

(60.1)

si + hi

1
= ---hi

P ( C i < C j j

C i = x ) dx

(60.2)

si
si + hi

1
= ---hi

j i P ( C i < C j

C i = x ) dx

(60.3)

si

si + hi

1
= ---hi

j i P ( Cj > x ) dx

si

1
= ---hi

464

sk + 1

P ( Cj > x ) dx
k=i
i

1
= ---hi

(60.4)

sk
sk + 1

x sj

-
1 ----------hj

k=i

sk

(60.5)

j = 1
ji

dx

(60.6)

j = 1
ji

PTV AG

Chapter 6.9: Headway-based assignment

Explanation of the derivation


In row (60.1), the entire passenger information is used. Line i is selected if its remaining costs
Ci are lower than those of the other lines. Row (60.2) reformulates the expression, by using the
density function of the random variable Ci. Due to constant headways Ci is equally distributed
in [si,si + hi). (If the wait time is weighted with a factor, this should be put in front of hi, the
calculation otherwise does not change.)
In row (60.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 (60.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
[sk,sk+1) the following must apply: P(Cj > 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 sk+1. In the last step we then apply
the distribution function of Cj which (60.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.
i s k + 1
k
i
1

E ( W L ) =

i = 1 ---h-i

( x si )

x sj

-
1 ----------hj

dx

j = 1
ji
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.
k=i

6.9.5

sk

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 459). 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.

PTV AG

465

Chapter 6: User model PuT

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 463) 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
via cell phone the information on the current timetable and - on the basis of operational realtime 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.

466

PTV AG

Chapter 6.9: Headway-based assignment

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 459).
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 467).

6.9.5.4

Example for the choice models

Let us look at the following network.

Illustration 153: 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.
2.
3.
4.
5.

No information, constant headways


Departure time information per stop, not available on board.
Departure time information per stop, also available on board.
Departure time information for all stops, not available on board.
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.

PTV AG

467

Chapter 6: User model PuT

Illustration 154: Structure of the choice in scenario 1 (no information)

In the illustration, circles represent lines and rectangles indicate stops.


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 155: 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.

468

PTV AG

Chapter 6.9: Headway-based assignment

Illustration 156: 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 159.
Line
1
2

Run time
Start -> A
A -> Destination

Headway

5
8

10

15

10

Table 159: Travel times and headways of the lines in the example network

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. The table 160 shows,
that the passenger can derive a much bigger advantage from these transfer alternatives, the
more information he has on the arising wait times.

PTV AG

469

Chapter 6: User model PuT

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 160: Line shares and the mean costs depending on the information available

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 459 and "The complete choice model" on
page 465).
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, these are known as decision points. The paths in
this graph represent the various options to reach the destination zone.

470

PTV AG

Chapter 6.9: Headway-based assignment

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 157 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 161 if these are calculated according to the method from mean headway (see
"Headway calculation" on page 454).
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 161: Headway calculation for the example

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.

PTV AG

471

Chapter 6: User model PuT

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.
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 162 are calculated for a passenger arriving at the
railway station on Bus 1 for the remaining route legs.

Egress time, walk time

Route 1

Route 2

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 162: Impedance calculation for the routes in the example

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.
33 18 15
=
= 0.25
78 18 60

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.

472

PTV AG

Chapter 6.9: Headway-based assignment

This results in the volumes shown in illustration 157.


A-Village

90

Station

X-City

23

67

B-Village

67

Illustration 157: Volume for headway-based assignment, transfer penalty 2 min

With any variation in the transfer penalty, this portion changes as shown in table 163. For other
impedance parameters, the same applies.
Transfer time penalty

Portion of Route 1
0 min

Portion of Route 2
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 163: Changes to shares with variation of the transfer penalty

The skim values for the relation from A-Village to X-City are shown in table 164. These values
are the mean skim data of both routes which weighted with the number of passengers are
summarized for the impedance parameters used here.
Route

Set

Pass. In-veh. time

Pass. TWT

Pass. Ride time

Pass. NTR

67.5

67.5 45 min

67.5 0 min

67,5 45 min

67,5 0

22.5

22,5 28 min

22,5 7,5 min

22,5 35,5 min

22,5 1

Total

90

3 667.5 min

168.75 min

3 836.25 min

22.5

3,667.5 = 90
= 40.75 min

168.75 / 90 =
1.875 min

3,836.25 = 90
42.625 min

22.5 / 90 = 0.25

Mean

Table 164: Mean skim values for the headway-based assignment

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

PTV AG

473

Chapter 6: User model PuT

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.

6.9.8

Coordination
In Visum, the coordination can be used for the headway-based assignment. 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.
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.
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. The illustration 158
shows an example.

H e a d w a y H 1 = 2 0 m in
re d
r e d - b lu e

H e a d w a y H = 1 0 m in

b lu e
Headway H

= 2 0 m in

Illustration 158: Coordination of lines

474

PTV AG

Chapter 6.9: Headway-based assignment

Considering only the red-blue line, a passenger arriving randomly has a mean wait time of 5
minutes precisely half the headway.
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.24.2, page 399) 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.24.2, page 399) to the other then
require precisely the specified duration each time (see User Manual, Chpt. 6.2.3.2,
page 1087).

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.
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.
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.

PTV AG

475

Chapter 6: User model PuT

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.

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. Ti 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 / T1 + ... + 1 / Tm)

This is the harmonic mean of the given Ti. The number of services corresponding to this
headway is equal to the sum of the number of services of the individual time profiles.
Example: T1 = 6, T2 = 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 / Ti.
This fraction is also used as the relative share of the demand within the time profile bundle,
i.e. pi := i. The aggregate impedance is again set to C := c1 p1 + + cm pm with ci =
impedances of the time profiles.
Using the standard algorithm (see "Route search" on page 471 and "Route choice" on
page 472), 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.

476

PTV AG

Chapter 6.10: Timetable-based assignment

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.

6.10

TP

Impedance

Headw
ay

Distinguishable (Standard)

Undistinguishable

24

0.0166

0.7692

20

0.3366

0.1538

16

10

0.6466

0.0769

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 reanalyzed 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.

PTV AG

Using the branch & bound option (see "Connection search using Branch and Bound" on
page 478), 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 "Connection search using shortest path
search" on page 480), only one connection is calculated for each departure time, as this

477

Chapter 6: User model PuT

6.10.2

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 "Connection search
using Branch and Bound" on page 478) - 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 "Connection search using shortest path
search" on page 480).
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 484)
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).

Connection search
Two methods are provided for the connection search: Shortest path search and Branch &
Bound.

6.10.2.1 Connection search using 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.

478

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 FacVehJImp
Besides the journey time and the number of transfers, also TSys-specific penalties are as
TSys-Imp among others. That is, how common distance-based fares can already be
considered during the search. The complete Visum fare model will take effect during the
connection choice. However, this is no restriction, since the approximate fare calculation
during the search is sufficient for the distinction between reasonable routes and useless
ones.
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.
(Partial) connections to a destination or intermediate node are evaluated and compared
with any other (partial) connection to the same point. Then it can efficiently be decided
which branches of the search tree can be continued (branch) and which have to be cut
(bound) (see "Dominance" on page 479 and "Bounding" on page 479).
It is possible to specify an upper limit for the number of transfers in a connection.

PTV AG

Chapter 6.10: Timetable-based assignment

Dominance
Pairwise comparisons are helpful for the identification of useless connections.
If a connection is in no respect more appropriate than another connection in the same temporal
position, then this connection is called dominated and will be discarded. This means in detail:
A connection c dominates a connection c, if

c lies within the time interval of c


NumTransfers (c) NumTransfers (c)
SearchImp (c) SearchImp (c)
and real inequality applies to at least one of the three criteria.

To compare two connections without defined temporal position (that means: without path legs
of the 'PuT line' type) the first rule is changed to the following: Journey time (c) journey time
(c).
Example:

Connection 1 dominates connection 2, since it is really located in the time interval of


connection 2 and because other indicators of connection 1 are either as good as those of
connection 2 or even better.
Connection 1 does not dominate connection 3, since the temporal positions differ,
nevertheless connection 1 might be useful for those passengers who want to depart later
though the indicators of connection 1 are worse.
Connection 1 does neither dominate connection 4, since connection 4 does not require as
many transfers as connection 1 which might be acceptable for some passengers though
this means a longer journey time.
Criterion

Connection 1

Connection 2

Connection 3

Temporal position

6:00 - 7:00

6:00 - 7:10

6:10 - 7:20

Connection 4
5:30 - 7:20

Number of
transfers

SearchImp

4,000

4,200

4,300

5,400

Dominance

---

Dominated by
conn. 1

---

---

Bounding
Besides the temporal position, the following rules are applied to exclude connections which
differ considerably from the optimum in one or several criteria:
A (partial) connection is deleted, if

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.

As a matter of principle, connections which are optimal in one of the three dimensions will not
be deleted in this step, even if they violated the rule of another dimension.

PTV AG

479

Chapter 6: User model PuT

6.10.2.2 Connection search using 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.

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 AVillage (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.

480

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).

PTV AG

Chapter 6.10: Timetable-based assignment

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

Impedance and Perceived journey time PJT of a connection


The impedance is a linear combination of perceived journey time (see "Perceived journey time"
on page 481), 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 483).

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
+ Origin wait time FacOWT
+ Transfer wait time FacTWT
+ Number of transfers FacNT
+ Number of operator changes FacOC
+ Extended impedance Factor

Notes

PTV AG

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).

481

Chapter 6: User model PuT

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.
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 vehicle journey.
The weighted wait time f(t) is thus defined as

(t - t0)n + c, if t < t1, and

f(t) = t, if t t1.

t1 and c result from the boundary conditions f(t1) = t1 and f'(t1) = 1, that is from the
differentiable composition of both parts of the function at position t1.

Essential is: t0 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 = t0.
Around t0, f(t) increases symmetrically.
With increasing t, function f(t) approaches the linear asymptote t.
482

PTV AG

Chapter 6.10: Timetable-based assignment

Example

By default, n = 2 and t0 = 5 is set.


Due to the boundary conditions f(t1) = t1 and f'(t1) = 1, t1 = 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) = t02 + c = 25 + 5.25 = 30.25

A transfer with time t = 3 results in a considerably better value:


f(3) = (3 - t0)2 + c = 22 + 5.25 = 9.25

A transfer with time t = 5 reaches the optimum:


f(5) = (5 - t0)2 + c = 02 + 5.25 = 5.25

If t continues to increase, the weighting deteriorates again, for example with t = 10:
f(10) = (10 - t0)2 + c = 25 + 5.25 = 30.25

6.10.4.2 Temporal utility of a connection


With the timetable-based procedure, the temporal utility of a connection is modeled as follows.

TaiEarly = amount of time that connection i departs earlier than desired for departure
interval a ( time series); = zero, if i departs within a or after a.
T

early

desired dep. time actual dep. time if actual dep. time < desired dep. time

else
0

TaiLate = amount of time that connection i departs later than desired for the departure
interval a ( time series); = zero, if i departs within a or before a.
T

late

actual dep. time desired dep. time if ( actual dep. time > desired dep. time )

else
0

TaiEarly FacTearly + Tailate FacTlate = temporal distance between connection i and


interval 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.
Note: For connections with no temporal position, T is always zero.
The table 165 shows an example for the calculation of Tearly und Tlate in the time interval
[06:00 AM;07:00 AM].

PTV AG

483

Chapter 6: User model PuT

Departure
05:30 a.m.

Tearly
30

Tlate
30

6:00

06:40 a.m.

7:00

07:10 a.m.

10

10

Table 165: Calculation of the temporal distance

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 the TSys of PuT lines, because fare points can also be
assigned to PuT-Aux (see "Revenue calculation using the fare model" on page 636).

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 "Impedance and Perceived
journey time PJT of a connection" on page 481). 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 308). The independence can
also be included in the distribution rule, if required (see "Independence of connections" on
page 485).

6.10.5.1 Distribution of trips over connections


The impedance of a connection i used in the connection choice in a time interval a is calculated
as follows.
a

R i = PJT i Fac PJT + Fare i Fac Fare + T i

early

Fac

early

+ T i

late

Fac

late

Optionally, each skim value which goes 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 Box-Cox transformation.
The impedance calculation is not linked to the actual connection choice, that is, even when
calculating the Box-Cox 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 xi the different path attributes. Here, the first m of them without restrictions
are to be Box-Cox-transformed (namely each into parameter i). i stands for the respective
coefficient. Then the following applies
m

Ri =

484

i = 1 i fi ( xi ) + i = m + 1 i xi
PTV AG

Chapter 6.10: Timetable-based assignment

where
i
x 1
fi ( x ) =
log x

i 0
i = 0

By including this impedance in one of the distribution models Kirchhoff, Logit, Box-Cox or
Lohse (see "Distribution models in the assignment" on page 308), 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 485).
As before, the proportion of a connection i of the total demand is calculated as follows:
g ( Ri )
p i : = -------------------- g ( Rj )
j

Here, g is the selected utility function (always antitonic). In the case of Logit thus g(x) = e-bx
applies.
Notes: As can be seen from the definition, when using the Box-Cox transformation for xi
generally xi 0 needs to apply. In case of i = 0, even xi > 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 Box-Cox transformation or caused by negative coefficients, Ri itself can be negative.
In that case, only the Logit utility function can be used, otherwise the assignment is
terminated with an error message.

6.10.5.2 Independence of connections


All distribution models presented (see "Distribution models in the assignment" on page 308)
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 wi, which describe the impact of other
connections on a connection i. The value range of wi is the interval [0.1]. If j has no impact on
i, then wi(j) = 0. If i and j are absolutely equal, then wi(j) = 1, meaning it is always wi(j) = 1.
The following values are used to calculate wi(j).

The temporal proximity of the connections with regard to departure and arrival
xi ( j ) =

Dep j Depi + Arr j Arri


2

The advantage of i over j in terms of the perceived journey time


yi(j) := PJTj - PJTi
The advantage of i over j in terms of the fare
zi(j) := Fj - Fi

PTV AG

485

Chapter 6: User model PuT

Thus, wi is defined as follows:


+
s z yi ( j ) + s y zi ( j )

x ( j)

wi ( j ) := 1 i 1 c min 1,

sx
s y sz

s +
s y := y
s y
where

if
if

yi ( j ) 0

yi ( j ) < 0

s +
s z := z
s z
and

if
if

zi ( j ) 0
zi ( j ) < 0

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 xi(j)
= 0, so that this value is equals to 1. If the time difference is xi(j) sx, the value becomes zero
and wi(j) = 0 also applies. Thus, sx 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 yi(j) = 0 and zi(j)
= 0) and 1 - c (when there is a significant difference between i and j). As with sx, sy+ or sy- is the
maximum temporal advantage or disadvantage of i, in which j can possibly have an impact.
With regard to the fare, the same applies to sz. The default setting leads to the following relation
of sy- = 2sy+ and sz- = 2sz+. 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:
sx = min (2 mean wait time of a random passenger between the first and the last departure, maximum
time slot)
sy+ = ECQH mean PJT in the total assignment period
sy- = ECQG mean PJT in the total assignment period
sz+ = ECQH mean fare in the total assignment period
sz- = ECQL mean fare in the total assignment period

Note: Only the temporal positions, the PJT values and the fares are compared; service trip
item data is not evaluated.
If no fares are available (i.e. FPi = 0 for all i), then sz = 1 is set.
The attribute independence of a connection is now defined as follows:
INDi :=
n

wi ( j )
j =1

=
1+

1
n

wi ( j )
j =1, j i

Here, n is the total number of connections.

486

PTV AG

Chapter 6.10: Timetable-based assignment

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 Uia of a
connection i was calculated. From this, its percentage in terms of the demand was determined
per time interval. If independence is applied, Uia INDi replaces Uia, i.e. the following applies:
U ia INDi
Pia =
n
U aj IND j
j =1

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.

Comparison of the choice models with independence


In table 167 to table 171 the different choice models are compared with each other, with and
without independence. The procedure parameters are chosen as in table 166.
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 166: Procedure parameters for the comparison of the distribution models

Connection data that differs from the respective previous example is highlighted bold in
table 167 to table 171. All assignment shares are given as percentages.

Lohse

Box-Cox

Logit

Kirchhoff

Distribution with IND


Lohse

Fare

Box-Cox

Arr

Logit

Dep

PJT

No.

Distribution without IND


Kirchhoff

Connection data

10

30

20

3.00

33.3

33.3

33.3

33.3

33.3

33.3

33.3

33.3

30

50

20

3.00

33.3

33.3

33.3

33.3

33.3

33.3

33.3

33.3

50

70

20

3.00

33.3

33.3

33.3

33.3

33.3

33.3

33.3

33.3

Table 167: Example 1 Initial situation

PTV AG

487

Chapter 6: User model PuT

Lohse

Box-Cox

Logit

Kirchhoff

Distribution with IND


Lohse

Fare

Box-Cox

Arr

Logit

Dep

PJT

No.

Distribution without IND


Kirchhoff

Connection data

10

30

20

3.00

25

25

25

25

33.3

33.3

33.3

33.3

30

50

20

3.00

25

25

25

25

16.7

16.7

16.7

16.7

30

50

20

3.00

25

25

25

25

16.7

16.7

16.7

16.7

50

70

20

3.00

25

25

25

25

33.3

33.3

33.3

33.3

Table 168: Example 2 Isochronous, identical pair of connections

Lohse

Box-Cox

Logit

Kirchhoff

Distribution with IND


Lohse

Box-Cox

Distribution without IND


Fare

Arr

Logit

Dep

PJT

No.

Kirchhoff

Connection data

10

30

20

3.00

25

25

25

25

32.7

32.7

32.7

32.7

30

50

20

3.00

25

25

25

25

17.3

17.3

17.3

17.3

32

52

20

3.00

25

25

25

25

17.3

17.3

17.3

17.3

50

70

20

3.00

25

25

25

25

32.7

32.7

32.7

32.7

Table 169: Example 3 Identical pair of connections with high temporal proximity

Logit

Box-Cox

Lohse

30

Kirchhoff

10

Distribution with IND


Lohse

Distribution without IND


Fare

Box-Cox

Arr

Logit

Dep

20

3.00

25.9

26.7

26.2

25.1

31.9

32.6

32.2

31.2

PJT

No.

Kirchhoff

Connection data

30

50

20

3.00

25.9

26.7

26.2

25.1

20.2

20.7

20.4

19.8

32

47

20

3.30

22.3

19.8

21.3

24.6

16.0

14.1

15.2

17.8

50

70

20

3.00

25.9

26.7

26.2

25.1

31.9

32.6

32.2

31.2

Table 170: Example 4 Similar pair of connections with high temporal proximity (connection 3 now
includes transfer)

Lohse

Box-Cox

Logit

Kirchhoff

Distribution with IND


Lohse

Fare

Box-Cox

Distribution without IND

Arr

Logit

Dep

PJT

No.

Kirchhoff

Connection data

10

30

20

3.00

23.5

21.9

22.8

24.6

26.5

24.9

25.8

27.7

30

50

20

3.00

23.5

21.9

22.8

24.6

20.1

18.9

19.6

21.0

Table 171: Example 5 - Differing pair of connections with moderate temporal proximity

488

PTV AG

Chapter 6.10: Timetable-based assignment

Connection data

Distribution without IND

Distribution with IND

32

44

17

3.30

29.6

34.3

31.5

26.1

26.9

31.4

28.7

23.6

50

70

20

3.00

23.5

21.9

22.8

24.6

26.5

24.9

25.8

27.7

Table 171: Example 5 - Differing pair of connections with moderate temporal proximity

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 172. 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).
Conn. i

Dep.

JRTi

TWTi

NTRi

PJTi = JRTi + TWTi FacTWT + NTRi FacNTR

6:10
a.m.

28 min

3 min

28 + 3 2 + 1 2 = 36

6:10
a.m.

45 min

0 min

45 + 0 2 + 0 2 = 45

06:55
a.m.

45 min

0 min

45 + 0 2 + 0 2 = 45

7:25
a.m.

28 min

8 min

28 + 3 2 + 1 2 = 36

7:25
a.m.

45 min

0 min

45 + 0 2 + 0 2 = 45

FacTWT = 2, FacNTR = 2
Table 172: Result of connection search (transfer penalty 10 min, parameter file TIMETAB1.PAR)

The table 173 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:
Ria = PJTi 1.0 + Tiaearly 1.0 + Tialate 1.0

PTV AG

489

Chapter 6: User model PuT

Conn. i

Dep.

Ti1

6:10 a.m.

Ti2

Ri1

Ri2

5:30-6:30

6:30-7:30

5:30-6:30

6:30-7:30

0 min

20 min

36 0 = 36

36 20 = 56

6:10 a.m.

0 min

20 min

45 0 = 45

45 20 = 65

6:55 a.m.

25 min

0 min

45 25 = 70

45 0 = 45

7:25 a.m.

55 min

0 min

46 55 = 101

46 0 = 46

7:25 a.m.

55 min

0 min

45 55 = 100

45 0 = 45

Table 173: Temporal distances T and impedances R of the connections for the two analyzed intervals of
travel demand

Then, a distribution rule (here Kirchhoff with = 3) is used to calculate the shares Pia which are
allocated to the individual connections. The independence is ignored in this formula. As shown
in table 174, all five connections are assigned non-zero percentages of the travel demand per
time interval.
Conn. i

Dep.

Pi1

Pi2

5:30-6:30

6:30-7:30

Vehicle

Vehicle

journeys Mi1
5:30-6:30

journeys Mi2
6:30-7:30

Vehicle
journeys
5:30-7:30

6:10
a.m.

57%

13%

30 0.57 = 17

60 0.13 = 8

25

6:10
a.m.

30%

8%

30 0.30 = 9

60 0.08 = 5

14

6:55
a.m.

7%

27%

30 0.07 = 2

60 0.27 = 16

18

7:25
a.m.

3%

25%

30 0.03 = 1

60 0.25 = 15

16

7:25
a.m.

3%

27%

30 0.03 = 1

60 0.27 = 16

17

100%

100%

30

60

90

Table 174: Distribution of trips to the connections (Kirchhoff, = 3)

This results in the volumes shown in illustration 159.

490

PTV AG

Chapter 6.10: Timetable-based assignment

A_village

90

X_city

Station

41

B_village

49

49

Illustration 159: 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 the 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 timetablebased
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: Export/Import of connections" on page 492)
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.

PTV AG

491

Chapter 6: User model PuT

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: Export/Import of


connections
For some projects particularly in connection with demand modeling (see "Demand model" on
page 119) a (time-consuming) timetable-based assignment is carried out several times within
the same procedure sequence.
The PuT skims are determined first, for example, then the mode choice is calculated and finally
the actual PuT assignment is performed. Since during the PuT skim calculation all connections
are already determined, it is reasonable to use them in the PuT assignment. Thus the
assignment includes only the step connection choice (see "Connection choice" on page 484).
The timetable-based assignment has such a modular structure that search and choice can be
performed independently of each other and the found connections can be stored for later use.
This provides the following advantages:

492

Replacing a connection search by a pre-calculated path file or by paths taken from an


already existing assignment saves lots of time. In many networks, the search is the most
time-consuming step of the computation. Possibly the peak memory requirements can be
reduced during the assignment.
Paths from external sources can be taken as inputs to the Visum assignment. This allows
for a user-defined heuristic during search and choice without resigning other advantages of
the Visum assignment.
Variants of assignment results can be stored via connection export and later be read in for
post-assignment analyses, if required. It is no longer necessary to use several version files.

PTV AG

Chapter 6.10: Timetable-based assignment

Preprocessing

(3)+(4)

Search

Wege from
Paths
aus
assignmentoder
Umlegung
or
aus Datei
from
file

(2a)
Assessment

(1)
Paths
belastete
with volumes
Wege
from
aus Datei
file

Path
Wegeexport
export without
ohne
volumes
Belastungen

Choice + path volumes

(2b)
Network volumes

Path export with


Wegeexport
mit
Belastungen
volumes

Illustration 160: Flow chart of a timetable-based assignment

The illustration 160 indicates when paths can be read in from file or output to file in the
timetable-based assignment. The following options are provided:
(1) External choice / Connection import
Connections with volumes are imported from file and stored like an assignment result,
therefore as paths and network volumes (see "Use case (1) External choice / Connection
import" on page 493).
(2) Connection export
In order to provide the external choice with data, connections can also be exported. You
can do so with or without volumes and optionally choose fare points, fares or user-defined
attributes (see "Use case (2): Connection export" on page 494).
(3) Using existing connections for the search
Instead of the connection search in Visum, the procedure can also use existing
connections as a basis. These connections can be the result of a previous assignment or
be stored in a connection file. 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 (see "Use case
(3) Using existing connections for the search" on page 495).
It is possible, but not necessary, to deactivate the option Calculate assignment for the
connection export. As for a pure skim calculation, neither paths not volumes are stored in this
case. Existing assignments of the selected demand segments are retained.

6.10.7.1 Use case (1) External choice / Connection import


The objective of the external choice is to assign volumes to a given number of connections
according to variable user-defined rules for later re-import of the connections in Visum so that
a usual assignment result will be available (see User Manual, Chpt. 13.3, page 1592).

PTV AG

493

Chapter 6: User model PuT

In the chart in illustration 160 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:

By default, the program deletes assignment results for demand segments to which
connection import is applied.
From the imported connections, paths are generated in Visum according to the current
setting of the option Save paths (as connections / as routes / do not save) (see User
Manual, Chpt. 6.1.1.2, page 1072).
The procedure setting Save paths as connections includes an option that allows you to
sum up the volumes of existing connections.
At the same time the path volumes read in are transferred into network volumes.
If the volumes of a demand segment that has been selected for the import are to be saved
with another demand segment according to the current general procedure settings, then
this parameter will be reset to the default (Do not save with a different demand segment).

6.10.7.2 Use case (2): Connection export


Using the connection export you create connection files to save computation time during future
assignments. You can also import this data in external tools in which you have set up your
specific heuristics for the connection choice.
The connection export can be performed with or without volumes. Volumes are required for the
connection import procedure. When exporting connections without volumes you can select one
of the following options for the export: Connections are to be searched on either all relations or
only on those relations with demand > zero.
The option Regard all relations should be used if the demand by relation is not known when
the export is performed. Typically this is the case during the PuT skim calculation at the
beginning of the Standard-4-step model calculation. Increasing computation time and growing
size of the connection file are the disadvantages of this option.
Independently of this option, exported connection files can also store the following data:

Fare points of the path legs (cannot be imported) and/or


Fares per path or path leg for a single or all demand segments (can be imported)
User-defined attribute for PuT paths

For fare calculations in the context of the external choice, the option with fare points has to
be enabled since the fare is mostly based on the number of fare points per path leg of the
connection.
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.

494

PTV AG

Chapter 6.10: Timetable-based assignment

6.10.7.3 Use case (3) Using existing connections for the search
At the beginning of the assignment you can re-use existing connections instead of a complete
connection search calculation. This will significantly speed-up the assignment and allows for
subsequent usage of external tools for the connection search.
The import can use data from various sources:

from a connection file


from an existing assignment result in the network

Once the import is finished the assignment will continue in the same way as after the internal
connection search. Especially the source does not have an impact on the connection choice
(see "Connection choice" on page 484).
Imported connections have preset times of arrival and departure which depend on the
assignment time interval that was set for their calculation. For the import, you can modify the
assignment time interval. In this case the temporal distance of the connections from the new
assignment time interval is DeltaT in the impedance as usual. In general this ensures, that
there is almost no demand for connections which are far outside. And they do not have a
significant impact on the skim calculation. Please note, that the skim service of frequency,
however, always regards the absolute number of connections not regarding their temporal
position. For this skim, identical assignment time intervals are recommended for the export and
import of connections.

Import from an existing assignment result


The usage of paths which were calculated in a previous assignment is similar to the PrT
assignment option Use current assignment result as initial solution (see User Manual,
Chpt. 5.6.2.2, page 1015). However, unlike PrT, the path search may be dropped completely
for public transport. You need to enter a demand segment for which an assignment has already
been calculated.
The existing assignment needs to satisfy the following recommendations, otherwise the paths
resulting from the assignment cannot be re-used:

A timetable-based assignment is required.


For the calculation, the option 'Save paths as connections' needs to be selected. Please
note that this setting differs from the default (see User Manual, Chpt. 6.1.1.2, page 1072).
The demand segment has to belong to the same mode as the demand segments which are
currently to be assigned.

Import from a connection file


Alternatively, you can read connections from a file.
For this purpose, use the same connection files as for the connection import procedure (see
"Use case (1) External choice / Connection import" on page 493). In contrast to this procedure,
the import from a connection file ignores the stored volumes, only the paths are read from file.
Connection files can be applied to any demand segment. Make sure that the paths from the
connection file and the mode of the currently to be assigned demand segments match.
The import automatically identifies the level of the stored fare information (see "File format for
connection import and export" on page 496). Please note, that the current option setting Save
imported fare data (see User Manual, Chpt. 6.1.1.2, page 1072) determines whether and how
these fares are imported.

PTV AG

495

Chapter 6: User model PuT

6.10.7.4 File format for connection import and export


Import and export of paths use a uniform data format which is binary due to the huge amount
of data.
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.
As soon as the size of the connection file exceeds the given size limit, another connection file
is created. The size limit ensures that even a connection export including a huge number of
paths (> 4 GB) can be read in later.
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. Level of fare data contained in the file (0 = no fares)
5. Indication on whether the file contains fares for all demand segments
6. Indication on whether the file contains connector nodes
7. Indication on whether the file contains volumes Number and codes of the assigned demand
segments for future allocation of volumes and fares when reading them in again. If you
import connections without volumes and fares per demand segment, no demand segments
are saved and their number is set to 0.
8. 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.
9. Definition of user-defined attributes on PuT paths
10. 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


BinaryVersionNo (4 byte-integer)
NumberOfFiles (4 byte-integer)
ContainsFarePoints (1 byte-integer)
LevelOfFareInformation (1 byte-integer)//value in {0,1,2}
FaresForEachDemandSegment (1 byte-integer)
ContainsConnectorNodes (1 byte-integer)
ContainesVolumes (1 byte-integer)
NumDemandSegments (4 byte-integer)
for each contained DemandSegment in key order:
{
DemandSegment.Code (string)
}
NumPuTTSys (4 byte-integer)
for each contained PuTTSys in key order:

496

PTV AG

Chapter 6.10: Timetable-based assignment

{
TSys.Code (string)
}
NumTimeProfiles (4 byte-integer)
for each contained TimeProfile in key order:
{
Line.Name (string)
LineRoute.Name (string)
Direction.Code (string)
TimeProfile.Name (string)
}
NumUserDefinedAttributes (4 byte-integer)
for each contained UserDefinedAttribute:
{
ID (string)
ShortName (string)
LongName (string)
Comment (string)
ValueType (4 byte-integer)
HasDefaultValue (1 byte-integer)
DefaultValue (8 byte-real)
MinimumValue (8 byte-real)
MaximumValue (8 byte-real)
NumDecPlaces (4 byte-integer)
MaxStringLength (4 byte-integer)
DefaultStringValue (string)
}
for each contained OD relation in key order:
{
SourceZoneNo (4 byte-integer)
DestZoneNo (4 byte-integer)
for each contained Connection:
{
ConnectionDepartureTime (4 byte-integer)
NumLegs (1 byte-integer)
for each contained ConnectionLeg in logical order:
{
DepartureTime (4 byte-integer)
LegIsPuTLine (1 byte-integer)
if LegIsPuTLine
{
TimeProfileIndex (see above) (4 byte-integer)
FromTimeProfileItem.Index (2 byte-integer)
ToTimeProfileItem.Index (2 byte-integer)
}
else // 2nd case, leg is of type PuTAux
{
TSysIndex (see above) (4 byte-integer)
FromNodeNo (4 byte-integer)
ToNodeNo (4 byte-integer)
}
if ContainsFarePoints (4 byte-integer)
{
NumFarePoints (4 byte-integer)
}
if LevelOfFareInformation = 2
{
if(FaresForEachDemandSegment){
for each contained DemandSegment in key order:
{
LegFare (8 byte-double)
}
}
else {
LegFare (8 byte-real)
}

PTV AG

497

Chapter 6: User model PuT

}
}
for each contained DemandSegment in key order:
{
Volume (8 byte-double)
}
if LevelOfFareInformation = 1
{
if(FaresForEachDemandSegment){
for each contained DemandSegment in key order:
{
ConnectionFare (8 byte-double)
}
}
else {
ConnectionFare (8 byte-real)
}
if ContainsConnectorNodes
{
FromNodeNo (4 byte-integer)
ToNodeNo (4 byte-integer)
}
for each contained UserDefinedAttribute:
{
HasValue (1 byte-integer)
if HasValue
{
Value (1 byte-integer/4 byte-integer/8 byte-double/string)
}
}
}
-1 (4 byte-integer)
}
-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)

For user-defined attributes the following applies:

498

The attribute values of a connection are saved in the same sequence as the attributes are
defined in the header.
The values permitted for ValueType correspond to those listed in the COM documentation
(cf. 2.1 INetObjCollection: AddUserDefinedAttribute). Formula attributes must not be
defined in the connection file. The corresponding data types are listed in the table below.

PTV AG

Chapter 6.10: Timetable-based assignment

Identifier

Numeric value

Data type

ValueType_Int

4 byte-integer

ValueType_Real

8 byte-double

ValueType_String

string

ValueType_Duration

4 byte-integer

ValueType_TimePoint

4 byte-integer
string

ValueType_Filename

ValueType_Bool

1 byte-integer

ValueType_LongLength

12

8 byte-double

ValueType_ShortLength

13

8 byte-double

ValueType_StringLong

62

string

ValueType_LongDuration

165

4 byte-integer

6.10.7.5 Consistency check during connection import


If a data conflict is detected, the procedure will be aborted. Conflicts can occur in the following
cases:

6.10.8

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

Capacity restriction
By default, the timetable-based assignment determines a connection's attractiveness without
taking the demand into account. Accordingly, the demand is distributed onto possible
connections without consideration of the vol/cap ratios of these connections. Regarding also
the vol/cap ratio can return those connections as attractive alternatives which in the standard
case seemed to be not attractive. Thus, the enhancement with this criterion might change the
set of possible connections.
Basically, neglecting the capacities is a simplification, which unsatisfactorily reflects reality in
highly loaded public transport systems. Capacity restrictions in practice can take effect in
different ways:

PTV AG

Absolute vehicle capacity: The vehicle can hold only as many passengers as preset by its
capacity.

499

Chapter 6: User model PuT

Discomfort in the vehicle: Passengers feel rather uncomfortable when travelling in a heavily
loaded vehicle. This effect will increases if all seats are occupied.
Discomfort outside of the vehicle: Passengers feel rather uncomfortable when transferring
at highly frequented stops. Besides unpleasant effects due to overcrowding also delays
may occur.

The timetable-based procedure's capacity restriction aims to model possible discomfort for
passengers in the vehicle. This approach approximately includes the fact that certain quantities
of the passengers have to use different connections if the vehicle capacity is saturated.
Exceeding the vehicle capacity is not prevented, however. Capacity-restricting effects at stops
are not regarded.

6.10.8.1 How the procedure works


Using the capacity restriction, the timetable-based assignment works as follows:
1. Connection search and preselection are calculated as usual.
2. If the option In the loaded network, search a second time has been checked, also the
connection choice is calculated and then both search and pre-selection will be executed a
second time. This second search will take the calculated volumes into account which result
from the choice: These volumes will be added to the search impedance. The purpose of the
second search is to find alternative connections, which could be dominated by other
connections in the first search. If this option is not checked, step 4 will follow (see User
Manual, Chpt. 6.2.4.7, page 1113).
3. If the option Merge the results of 1st search and 2nd search is checked, both sets of
connections will be summarized. If this option is not checked, the following steps will use
only the connections that were returned by the second search (see User Manual, Chpt.
6.2.4.7, page 1113).
4. Based on this set of connections, all impedances which do neither depend on the vol/cap
ratio nor on the time interval will be calculated, since this set of connections will not change
in the subsequent loop.
5. This step is the start of the actual loop: First, vol/cap ratio-depending impedances are
calculated (see User Manual, Chpt. 6.2.4.8, page 1116). The following three options are
available (see "Calculation of Vol/Cap ratio-dependent impedances" on page 501).
6. Optionally, the calculated impedances are smoothed (see User Manual, Chpt. 6.2.4.7,
page 1113). Here, you can choose from two methods (see "Smoothing of impedances" on
page 503).
7. Alternatively, the steps 7 and 8 are to be applied.
Now, the choice model determines the volumes by connection. Since this computation is
performed by time interval, the time interval-depending impedances are included. These
are added to the other impedance components.
If the option Shift volumes among adjacent connections has been checked, the new
volumes result from volume shifting from overloaded connections to alternatives (see User
Manual, Chpt. 6.2.4.8, page 1116). This is done without differentiation by time interval (see
"Distribution of volumes onto alternatives" on page 504).
8. In order to prevent oscillations between heavily loaded connections, optionally the changes
to the volumes are smoothed (see "Smoothing of the vol/cap ratios" on page 503). This
step is performed as an alternative to the impedance smoothing, cf. step 6.

500

PTV AG

Chapter 6.10: Timetable-based assignment

9. Various measures are calculated and returned which describe the distance from the
balanced state.
10. The termination conditions are verified. The procedure will be cancelled, if one of the
criteria is satisfied, otherwise the calculation will continue with step 5.
Supplementary remarks about the modified procedure:

During the choice, vol/cap ratio-depending impedances are added to the other impedance
components, i.e. they also go into the skim Impedance.
Also connections can be exported in combination with the capacity restriction. If
connections are exported without volumes, the export will start after the second search is
finished. If connections are exported with volumes, the export will start after the final choice.
Skim matrices and other output data will be calculated after the final choice.

Taking the capacity restrictions into account causes further restrictions with regard to three
points:

The optional second search is only possible with the Branch & Bound method.
If volumes are shifted between connections, the calculation of relevant skims will not take
time interval-specific volumes into account. This notably means that neither the skim
Adaptation time nor the skim Extended adaptation time can be calculated and output if
this option has been selected. Since the volumes are not directly derived from the choice
model if volumes are shifted between connections, even the skim Utility cannot be
calculated. For the skim Impedance, the DeltaT portion (which is the difference between
desired departure time interval and actual departure time) cannot be calculated.
Information on the calendar day level is neglected, since just a single vol/cap ratio is
determined per vehicle journey item. In reality, however, vehicle journeys could actually run
on several valid days, and their capacities and volumes might differ. Thus the applied vol/
cap ratio definition represents a simplification of the information provided with the Visum
data model, if a calendar is used.

6.10.8.2 Calculation of Vol/Cap ratio-dependent impedances


With each of the three options, the vol/cap ratio Av of vehicle journey item v is calculated as
follows:

Volume v ( AP )
A v = -------------------------------Capacity v
The capacity v corresponds to the value of the attribute, which has been selected by the user
for the capacity of a vehicle journey item. The pre-set default amounts across all vehicle
journey sections, which service the vehicle journey item without regard to the calendar day.
Thus the volume of a vehicle journey item sums up from the volumes of all connections using
this item:

PV =

PV

Vwith v V

Path legs covered with PuT-Aux are not regarded for the vol/cap ratio-dependent impedance
calculation.

PTV AG

501

Chapter 6: User model PuT

Calculation from the assumed standing minutes (German Rail (DB))


The assumed standing minutes (E) are the mean value of the time, a passenger expects to find
no seat during his ride if passengers have random access to the seats on each stop-stop
relation. The latter is due to the fact, that it cannot be distinguished between passengers who
are already on board before the overloaded route section is reached and passengers who
board in this route section. This interpretation of the standing minutes applies to the capacity
of a vehicle journey item definition with regard to the number of seats. More generally, this is a
discomfort which increases with the vol/cap ratio.
For a vehicle journey item v, the standing probability is approximated by a potentially
asymptotical function:

1 S v = ----------------------a
1 + b Av
The user has to set the parameters a and b, and Av is the vol/cap ratio.
The expected standing minutes of a connection V correspond to a volume-dependent
impedance and result from adding the product of standing probability and run time across all
vehicle journey items of the connection:
:W v =

S v run time v

vV

Using a penalty function for computation (Swiss Rail (SBB))


The impedance of a vehicle journey item v is defined as follows:
b
a Av , Av l1

2
Wv = r + Av + Av + A3 , l < A < l
1
v
2
v

Av l2
c,

The parameters a, b, c, l1 and l2 have to be entered by the user, Av is the vol/cap ratio of vehicle
journey item v. Thereof, the parameters r, , and result due to the function which can be
constantly differentiated here l1 and here l2.
Thus, the impedance of a connection V is calculated as follows:

WV =

v V Wv run timev

Using a linear penalty function for computation (Linear)


The impedance of a vehicle journey item v is defined as follows:

W V = max ( 0,a A v + b )
a and b are user-defined parameters, Av is the vol/cap ratio of a vehicle journey item v.

Thus, the impedance of a connection V is calculated as follows:

502

PTV AG

Chapter 6.10: Timetable-based assignment

WV =

v V Wv run timev

6.10.8.3 Smoothing of impedances


For smoothing of vol/cap ratio-dependent impedances, one of these methods can be chosen:
Exponential smoothing or Method of Successive Averages (MSA). After smoothing of
impedances, subsequent steps will use the smoothed impedances instead of the real
impedances.

Exponential smoothing
According to this formula, the smoothed vol/cap ratio-dependent impedance of connection V in
iteration i is derived from both the calculated impedance and the smoothed impedance of the
previous iteration:

V, i

smoothed

= a W V , i 1 smoothed + ( 1 a ) W V, i

Parameter a has to be defined by the user, the value range is 0..1.

Method of Successive Averages (MSA)


According to this formula, the smoothed vol/cap ratio-dependent impedance of connection V in
iteration i is derived from the impedances of the previous iterations:

V, i

smoothed

i
1
= ----------- W V, i 1 smoothed + ----------- W V, i
i+1
i+1

This procedure forces convergence of impedances and of volumes, accordingly.

6.10.8.4 Smoothing of the vol/cap ratios


To prevent heavy oscillations of volumes between some connections, the vol/cap ratios of
vehicle journey items can be smoothed. Actually, the vol/cap ratio of a vehicle journey item in
iteration i is derived as follows:

P v, i
A v, i = ----------------------- ( = : A v, i out )
Capacity v
The smoothed vol/cap ratio of a vehicle journey item in iteration i is derived from the calculated
and the smoothed vol/cap ratios of the two previous iterations:

A v, i smooth ( A v, i 2 smooth A v, i 1 ) A v, i 2 smooth ( A v, i smooth A v, i )


A v, i smooth : = ------------------------------------------------------------------------------------------------------------------------------------------------------( A v, i 2 smoothed A v, i 1 ) ( A v, i smoothed A v, i )
This

formula

A v, i 2

PTV AG

smoothed

describes

A v, i 1

the
and

interpolation

A v, i

smoothed

in

the

event

of

different

signs

for

A v, i .

503

Chapter 6: User model PuT

Illustration 161: Smoothing of the vol/cap ratio in iteration i

In the image, the following applies:

A v, i in = A v, i smoothed

and

A v, i out = A v, i

etc.

If both terms have the same sign, an extrapolation will be performed. Using the same formula
slows down the convergence for the extrapolation, thus the following formula is used in this
case (smoothing with constant factor 0.5):

A v, i smoothed + A v, i
A v, i smoothed = -----------------------------------2
The smoothed vol/cap ratios are then regarded by the impedance calculation within this
iteration and by the final impedance calculation.
For a network with smoothed vol/cap ratios of vehicle journey items it cannot be assumed, that
a path set can be generated which could generate the corresponding volumes.

6.10.8.5 Distribution of volumes onto alternatives


In order to prevent volumes from being distributed too often to connections which are
unattractive in terms of time, instead of the choice model a procedure can optionally be
applied, which shifts volumes between connections.
In this case, for each pair of connections (V, V') it is calculated to which extent the volumes of
connection V are shifted to connection V'. The particular formula is:

P V, V'

P V' B e ESm V' d V ( t V' )


= ------------------------------------------------------------------- P V' B
B
ESmW d V ( t W )
W PW e

PvB is the volume of connection V before shifting, W is the set of possible alternative
connections. The function d is defined as follows:

d V ( t ) = 0, if abs ( t t V ) > c ESm V

504

PTV AG

Chapter 6.10: Timetable-based assignment

abs ( t t V )
d V ( t ) = 1 -------------------------, else
c ESm V
c and are user-defined parameters. This function has the effect, that connections which are
outside of a tolerance in terms of time are not regarded as alternatives. For permitted
connections, however, the readiness to change connections (alternating standby) increases
with an alternative's decreasing temporal distance from the original connection.

The diagram below shows an example of the function d for a connection V with
ESm V

= 5min

and c = 10:

Illustration 162: Readiness to change dependent on the alternative's departure time

Then, the new volume of connection V results from:

PV =

P V', V
V'
Shifting volumes between connections also means new volumes for all vehicle journey items.
This method does not take the independence of connections into account.
Note: Optional shifting of volumes between adjacent connections is only provided with the DB
impedance function.

6.10.8.6 Distance of the current solution from the balanced state


Depending on the applied smoothing method, the differences can be computed between
smoothed and non-smoothed impedances or vol/cap ratios. The skims below describe the gap
between the current solution and a balanced state. Using these skims it becomes obvious,
whether and to which degree the balanced state has been reached.
With smoothed impedances, the following skims are calculated:

PTV AG

505

Chapter 6: User model PuT

1
GapEuclidi = ---- ( W V, i smoothed W V, i ) 2
N V
1
GapAbsolute i = ---- W V, i smoothed W V, i
N V

GapMax i = max V ( W V, i smoothed W V, i )


Accordingly, in case of vol/cap ratio-based smoothing:

1
GapEuclidi = ---- ( Al v, i smoothed Al v, i ) 2
N V
1
GapAbsolute i = ---- Al v, i smoothed Al v, i
N V

GapMax i = max V ( Al v, i smoothed Al v, i )


Here, N is the number of connections.

6.10.8.7 Termination criteria


The procedure will terminate if at least one of the following criteria is satisfied:

The number of iterations exceeds the user-defined maximum number of iterations.


The changes to all vehicle journey item volumes in total do not reach a given maximum
threshold. For the evaluation, the following inequality is used:

Volume v, i Volume v, i 1 a max ( Volume v, i 1 ,Volume v, i ) + b


a and b are user-defined parameters. Satisfying the second criterion does not automatically
mean that the equilibrium state has been reached. It just means that volumes and thus also
impedances will no longer change. Usually, this condition is forced by the smoothing methods.

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:

506

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

PTV AG

Chapter 6.11: Assignment analysis PuT

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 userdefined 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.
Note: An assignment result is no longer necessary in order to calculate the correlation
coefficient.
The table 175 shows the calculation rules for the output attributes of the assignment analysis.
The following applies to the formulas:
Z
U
N

PTV AG

Observation (count or measurement)


Calculation (assignment or network model)
Number objects with an observed value > 0

507

Chapter 6: User model PuT

AbsRMSE
Abs RMSE

Absolute root of mean square deviation


Significant differences between counted and modeled values have a higher
impact according to

( ) = (Z i U i )2
i =1

N1 2

Intercept
Intercept

Coefficient b in linear regression


Cf. Excel, Linear Regression (y = ax + b)

Percent acc GEH


Percent with acc GEH

Percentage objects with acceptable GEH value (per network object)

GEH (i ) =

(Z i U i )2
(Z i + U i ) 2

Percent avg rel E


Percentage objects within tolerance
Percent with avg rel error abs ( Z U )
i
i

------------------------------ Tolerance ( U )
Ui

NumObs
Number of 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)

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.

MeanAbsE

Mean absolute error


Mean deviation of absolute values(a)
(Difference between observed and modeled value)

( a ) =
MeanObs

1
Abs(Zi U i )
N
1

Mean observed value N

Zi

Table 175: Calculation rules for the output attributes of the assignment analysis

508

PTV AG

Chapter 6.12: PuT Passenger surveys

MeanRelE

Mean relative error


Mean deviation of absolute values in % (p) according to

( p ) = Abs(ZZi U i )

R2

Coefficient of determination r2
Cf. Excel function RSQ

RelRMSE

Relative root of mean square deviation

(Z i U i )2
Zi N

(N 1)

StdDev

Standard deviation

Slope

Coefficient a in linear regression


Cf. Excel, Linear Regression (y = ax + b)

Table 175: Calculation rules for the output attributes of the assignment analysis

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


Loading data from file and conversion of data records into PuT paths (see User Manual,
Chpt. 6.12.3, page 513).
Note: From each survey data record (which means per questionnaire or per ticket,
respectively), a passenger trip is generated and stored as PuT path.

Plausibilization of survey data


Verification and completion of the survey data records which contain the basic passenger
trip data (see "Plausibilization of survey data" on page 513).

PTV AG

509

Chapter 6: User model PuT

Direct assignment
Assignment of the survey data records (calculating network volumes from path volumes),
optionally OD matrices and skim matrices can be generated (see "Assignment of survey
data" on page 519).
Note: Subsequently, indicator data on path level (by survey data record) is automatically
provided in the PuT paths list.

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 697) or PuT operating indicators (see "PuT operating indicators" on page 605).

6.12.1

Basic data of a passenger trip


Preceding line

Survey line

Succeeding line

Dest. terminal
Line i
Origin terminal
Line i

OriginStop

1st Transfer

Dest. terminal
Line j

Origin terminal
Line j

BoardStop

AlightStop
2nd Transfer

Origin terminal
Line k

Dest. terminal
Line k
DestStop

Route of passenger trip


Origin / Destination of a line
Passengers origin, boarding, transfer,
alighting or destination stop

Attribute

Description

Survey line

Designation of the line, where the passenger is encountered

Preceding/Succeeding

Path legs traveled by passenger which are 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)

510

Origin terminal

First stop of a vehicle journey

Destination terminal

Last stop of a vehicle journey

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

PTV AG

Chapter 6.12: PuT Passenger surveys

Attribute

Description

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

Standard questionnaire
Questionnaire
Line:

Bus 1

Orig.Term:

A village

Departure:

6:10

Route
Preced. 2:
Preced. 1:

Y town

42

Boarding:

Station

20

Alighting:

B village

30

Suceed. 1:
Suceed. 2:

Ticket
One-Way

Season

Group

Number of Persons:

Illustration 163: 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.
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.

The illustration 163 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. The
illustration 164 illustrates this procedure schematically.

PTV AG

511

Chapter 6: User model PuT

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.

512

PTV AG

Chapter 6.12: PuT Passenger surveys

Survey
Records
file
T he user checks the survey data
records that are not plausible and
discards or corrects them m anually.
Subsequently, the plausibilization can
be repeated.

Import
survey
records

Incom plete
survey records
in memory

Survey
Records
file

Log
file

Check and
com plete
survey
records

Com plete
survey records
in memory

Direct
As signment

Assignment
result
in memory

any post-assignm ent


analysis

Illustration 164: Processing of PuT passenger surveys

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.

6.12.3

Read survey data


This method loads survey data records from text files (one file 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.3.2, page 1125).

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.

PTV AG

513

Chapter 6: User model PuT

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.

Plausibilization: Basic approach


As a rule, the plausibilization includes the following steps.
1. Validity check of the survey path leg (illustration 165)
2. Validity check of the preceding section (illustration 166)
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: 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 1122).
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 1124).

514

PTV AG

Chapter 6.12: PuT Passenger surveys

Validity check of the survey path leg


State of plausibilization: Survey line

Path leg of survey line


from data record

E1

E2

E3

E7

E8

E9

E5

plausible
not plausible

Cf. list of survey path leg states 0..9 below

Check for a vehicle journey from


BoardStop to AlightStop in surveyed
time profile (or line route or line) with
departure within the valid range.*

YES
E1

NO

Other criteria for


direct validity check?

YES

NO

YES

NO

E2
YES
E3

nein

Connection search permitted?

E7

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.*

Check for (in)direct connection


from BoardStop to AlightStop
with departure within the valid range.

E5
YES

E8
NO
E9

not
plausible

plausible

Illustration 165: 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.

PTV AG

515

Chapter 6: User model PuT

Validity check of prec. section (Example with 1 or 2 prec. path legs)


Survey line is plausible
(i.e. departure time
and preceding stops
and further information
available)

Plausibilization state of preceding path legs:


V1

V2

V3

V4

V5

V6

ViT plausible
V9

not plausible

ViT = Status of the inner path leg

Check inner path leg


PreStop - BoardStop, regard given
arrival time at BoardStop

Vm = Max (Status of inner path leg / Status of outer path leg)


Cf. list of preceding/succeeding path leg states 0..9 below

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.*

YES
V1

NO

Other criteria
for direct validity check?

YES

Find vehicle journey from PreStop to


BoardStop in one of the time profiles of the
preceding line or in all TPs of the network.*

YES

Find (in)direct connection from PreStop to


BoardStop matching the survey lines
departure from the BoardStop.

V3

NO

Connection search permitted


for a single path leg?

YES
V5

NO

Find another
preceding path leg
YES

V2
YES

NO

Check outer path leg


OrigStop - PreStop,
regard given arrival time at PreStop

Find another
preceding path leg

YES

ViT NO

V9

not
plausible

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

NO
V9

NO

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.*

Is option
Connection search
active for remaining
preceding section?
YES

V9

Vm

V9
NO

Find an (in)direct connection


from OrigStop to BoardStop
with arrival at BoardStop
matching the survey lines
departure time from the
BoardStop.
YES

NO

YES

Connection search permitted


for a single path leg?

Is option Direct
connection active?

YES

NO

NO

YES

V4 YES

Find direct connection from


OrigStop to BoardStop with Journey
time Factor + constant < Journey time
of multi-part preceding section.

NO
Vm

YES

Find (in)direct connection from OrigStop


to PreStop with arrival at PreStop
matching the inner path legs departure
time from the PreStop.

Vm
YES

Is the found connection


an indirect one?

NO
V6

Illustration 166: 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 166).

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:

516

for the surveyed path leg E in table 176,


for the preceding section V in table 177,

PTV AG

Chapter 6.12: PuT Passenger surveys

for the succeeding section N in table 178,


for the entire survey data record G in table 179.

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.

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.

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.

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.

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.

Implausible, because no connection from boarding to alighting stop starting in the given time
frame could be found during connection search calculation.

Table 176: 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.

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.

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.

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 177: Status indicators for the preceding section

PTV AG

517

Chapter 6: User model PuT

Status indicators for the preceding section (V)


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).

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.

Table 177: Status indicators for the preceding section

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.

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.

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.

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.

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).

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 178: 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 179: Status indicators for the entire survey data record

518

PTV AG

Chapter 6.12: PuT Passenger surveys

6.12.5

Assignment of survey data


Direct assignment means assignment of a demand segments plausible paths to the network
(see User Manual, Chpt. 6.3.4, page 1139).
Subsequently, any of the post-assignment analyses provided for public transport can be
carried out.

PTV AG

Volume display as bars along links (see "Tabular and graphical display" on page 725)
Flow bundle calculations (see "Flow bundles" on page 697)
Skim matrix calculation on the basis of directly assigned paths (if not already calculated at
the direct assignment) (see "PuT skims" on page 437)
Calculation of PuT operating indicators, for example for the line costing and revenue
calculation (see "PuT operating indicators" on page 605)

519

Chapter 6: User model PuT

520

PTV AG

Operator model PuT


The PuT operator model in Visum comprises the PuT operating indicators and the PuT line
blocking procedure.

Subjects

7.1

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)

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 vehicle journeys per
line route) [Attribute: Number of service trips])
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 vehicle journey)
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:

PTV AG

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 vehicle journey)
Distribution of the fare revenues onto operators of a PuT supply
Distribution of the fare revenues onto local authorities (counties, municipalities)

521

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 vehicle
journeys which are run successively by one vehicle combination (see User Manual, Chpt. 7.1,
page 1157) 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 vehicle journeys of specific line using lowfloor 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 1219)
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 948)
Differentiated according to the objects of the line hierarchy. These include main lines, lines,
line routes, line route items, time profiles, time profile items, vehicle journeys and vehicle
journey 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 1219). The results of the procedure can be found in the Territories 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):

522

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

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.
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 180: Level Territory x Transport system

Note: Not every indicator is available for all aggregation levels. In the IndicatorAvailability.xls,
under ...Program files\PTV Vision\PTV Visum 13\Doc\Eng, you can find tables specifying the
aggregation levels on which the indicators are available.

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 581). The files IndicatorSource.xls and IndicatorAvailabilityxls, listed
under ...Program files\PTV Vision\PTV Visum 13\Doc\Eng, specify which indicators are
available on which evaluation level. 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 indicator's share, which applies to the polygon
will be returned (see "Territories" on page 52). The example network of Karlsruhe contains six
territories (illustration 167). 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.

PTV AG

523

Chapter 7: Operator model PuT

Illustration 167: 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 vehicle journeys (number of vehicle journeys 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
Center

Stop points total

Line network length directed (Bus) [km]

Number of service trips (AP)

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

96

58.474

1,888

Suburbs

Table 181: Indicators for line route analysis by territory

524

PTV AG

Chapter 7.1: Application areas and scope of operations

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.
Territory
Center

ServiceKm(AP) [km]

Revenue length-proportional (AP) [CU]

Revenue per ServiceKM


[CU/km]

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

6,328

40,159.07

6.35

11,191

4,736.75

0.42

West
Suburbs

Table 182: Territory-based indicator data for transport performance and revenue analysis

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. The table 183 shows the passenger kilometers and
the number of passenger trips (number of passengers boarding) for line 2 in the territories,
which are traversed (illustration 168). For this evaluation, the aggregation level Territory x
Line was selected (see User Manual, Chpt. 7.3, page 1219). This is how you can determine
how many passenger kilometers of the line apply to the fare zones.

PTV AG

525

Chapter 7: Operator model PuT

Illustration 168: Line 2 traverses several territories


Territory

Line

PassengerKm(AP) [km]

Passenger trips unlinked

Center

80,590

30,533

East

21,021

9,479

West

4,356

6,021

Table 183: Territory-based analysis on aggregation level Territory x Line

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. The table 184 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.

526

PTV AG

Chapter 7.1: Application areas and scope of operations

Index

Line route
name

Direction
code

2_H

>

Node number
105497581

Stop point name

Vol/Cap ratio
Seats [%]

Wolfartsweier Nord

2_H

>

105224474

2_H

>

105224473

2_H

>

105497580

2_H

>

105497579

Durlach Zndhtle

10
10

2_H

>

105226816

10

2_H

>

105226814

10

2_H

>

105226812

10

2_H

>

105222467

10

10

2_H

>

105497578

...

...

...

...

Aue Friedhof / Steiermrker Str.

11

...

...

106

2_H

>

107

2_H

>

100521

Kussmaulstrasse

41

100522

Hertzstrasse

26
21

108

2_H

>

100523

Feierabendweg

109

2_H

>

100524

Neureuter Strasse

110

2_H

>

105496077

111

2_H

>

100525

Siemensallee

112

2_H

>

100526

Lassallestr

Table 184: Analysis of the Vol/Cap ratio of seats on the line route level

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.
Line name

Transport system

R92

TRAIN

Service kilometers [km]


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 185: Service kilometer analysis on the level of lines

PTV AG

527

Chapter 7: Operator model PuT

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

Transport
system

Costs [CU]

Revenue total Revenue


Cost cov. total Cost cov. / Cost cov.
[CU]
PTrip [CU] [CU]
PTrip [CU] [%]

21

BUS

433,831.31

22

BUS

254,736.07

314,551.88

0.53

23

BUS

487,624.88

214,824.83

0.55

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.44

-27,030.78

-0.03

94.02

42

BUS

361,669.22

868,201.73

0.52

506,532.51

0.30

240.05

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

773,477.34

0.56

339,646.03

0.25

178.29

59,815.80

0.10

123.48

-272,800.05

-0.70

44.06

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

551

BUS

142,190.73

306,929.17

0.59

164,738.44

0.32

215.86

Table 186: Cost and revenue computation on the level of lines

528

PTV AG

Chapter 7.1: Application areas and scope of operations

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.
Operator name

Service kilometers [km]

Seat kilometers [km]

TOK Tram Operator

12,071

1,092,238

DB German Rail

23,906

2,165,751

9,096

454,811

KBB Bus Operator

Table 187: Evaluation of transport performance indicators on the level of operators

7.1.2.5

Indicator data by time slice

If you are working with analysis time intervals (see User Manual, Chpt. 4.2, page 948), you can
evaluate most indicators broken down in time slices (see "PuT operating indicators" on
page 605). 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 1hour-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.
Operator name: KBB Bus Operator
ServiceKm (05:00 a.m.)

227.0

ServiceKm (06:00 a.m.)

622.2

ServiceKm (07:00 a.m.)

689.9

ServiceKm (08:00 a.m.)

602.4

ServiceKm (09:00 a.m.)

487.2

ServiceKm (10:00 a.m.)

443.0

ServiceKm (11:00 a.m.)

461.7

ServiceKm (12:00 a.m.)

537.2

ServiceKm (01:00 p.m.)

604.5

ServiceKm (02:00 p.m.)

541.9

ServiceKm (03:00 p.m.)

608.7

ServiceKm (04:00 p.m.)

710.2

ServiceKm (05:00 p.m.)

695.7

ServiceKm (06:00 p.m.)

626.8

ServiceKm (07:00 p.m.)

406.1

Table 188: Evaluation of service kilometers per time interval for the bus operator

PTV AG

529

Chapter 7: Operator model PuT

Operator name: KBB Bus Operator


ServiceKm (08:00 p.m.)

263.1

ServiceKm (09:00 p.m.)

203.1

Table 188: Evaluation of service kilometers per time interval for the bus operator

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.
Time interval
05:00 a.m.

Service kilometers [km]

Passenger kilometers
[km]

227.0

3,101.9

Passenger kilometers
--------------------------------------------------------- [ - ]
Service kilometers
13.7

06:00

622.2

14,034.9

22.6

07:00 a.m.

689.9

24,411.3

35.4

08:00

602.4

15,663.0

26.0

09:00 a.m.

487.2

4,785.9

9.8

10:00 a.m.

443.0

5,518.6

12.5

11:00 a.m.

461.7

7,902.9

17.1

12:00 a.m.

537.2

7,785.6

14.5

1:00 p.m.

604.5

13,961.9

23.1

2:00 p.m.

541.9

14,275.4

26.3

3:00 p.m.

608.7

12,241.2

20.1

4:00 p.m.

710.2

11,603.5

16.3

5:00 p.m.

695.7

7,215.4

10.4

6:00 p.m.

626.8

4,747.2

7.6

7:00 p.m.

406.1

1,731.9

4.3

8:00 p.m.

263.1

672.1

2.6

9:00 p.m.

203.1

258.4

1.3

Table 189: PassengerKm-to-ServiceKm ratio for the Bus operator

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. Relations among these network
objects and their relations to other network objects are illustrated by illustration 169.

530

PTV AG

Chapter 7.3: Typical work flow in the PuT operator model

Vehicle and Operator allocation at the line hierarchy

0..1

Operator

Standard Op.

0..1

Line

0..n

VehComb

StdVehComb

0..1

0..1

Time profile

VehUnit

0..1

StdVehComb
1..n

Operator

Vehicle journey

VJ section

Transport system

VehComb

Legend
Standard Op.

Operator that is s uggested when


creating a new vehicle journey.

StdVehComb

Vehicle combination that is suggested


when creating a new vehicle journey.

0..n
VehComb

VehUnit

Read: at the vehicle combination, 0 to n


vehicle units are allocated.

Illustration 169: Allocation of vehicles and operators in the line hierarchy

7.3

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.

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 1080).
2. Creating PuT vehicles (see User Manual, Chpt. 2.28, page 439) 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 1232).

PTV AG

531

Chapter 7: Operator model PuT

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 1215).
5. Parameterization and calculation of the PuT line blocking procedure (see User Manual,
Chpt. 7.1, page 1157).
6. Definition of the reference frameworks for evaluations
Definition of territories (see User Manual, Chpt. 2.22.1, page 369) and selection of the
aggregation level for evaluations by territory (see User Manual, Chpt. 7.3.2,
page 1220).
Definition of analysis time intervals for evaluations by time slice (see User Manual,
Chpt. 4.2, page 948).
Definition of operators (see User Manual, Chpt. 2.27.1, page 438) and allocation to
vehicle journeys.
Definition of the projection factor (see User Manual, Chpt. 2.42, page 645).
7. Calculation of the Territory indicators procedure (see User Manual, Chpt. 4.4.3, page 970).
8. Calculation of the PuT operating indicators procedure for the desired indicator classes (see
User Manual, Chpt. 7.3, page 1219).

7.4

Line blocking
Subjects

7.4.1

Introduction to 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

Introduction to 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 197.

532

PTV AG

Chapter 7.4: Line blocking

Fundamental terms
The basis of the line blocking efforts is the timetable with the vehicle journeys, which are to be
run by the blocks (Visum creates the blocks on the level of vehicle journey 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 pullin or pull-out. This difference is important when selecting the option Interlining permissible (see
User Manual, Chpt. 7.1.3.2, page 1169). For pull-in or pull-out without change of location,
neither empty trips nor empty kilometers accumulate.
As displayed in the illustration 170, the following times are included.

Interlining times
Time required for interlining trips between two vehicle journeys which end/start at different
stop points.
Layover
Layover time at a stop until next vehicle journey 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.
Pull-In

Service

Stand

Service

Stand

Service

Stand

Interlining

Service

Pull-Out

Stop1

7:00

8:00

Stop2

Stop3
6:00

9:00

10:00

11:00

Illustration 170: Example line block with pull-out trip, interlining trip and pull-in trip

PTV AG

533

Chapter 7: Operator model PuT

No.

Action

FromStop

ToStop

Dep

Arr

Pull-Out

Stop3

06:00
a.m.

06:30
a.m.

Vehicle journey Stop3

Stop1

06:30
a.m.

07:15
a.m.

Interlining

Stop1

Stop2

07:15
a.m.

Layover

Stop2

Stop2

Vehicle journey Stop2

Layover

Time

Length

30 min

10 km

45 min

30 km

07:30
a.m.

15 min

10 km

07:30
a.m.

08:00
a.m.

30 min

0 km

Stop1

08:00
a.m.

08:15
a.m.

15 min

10 km

Stop1

Stop1

08:15
a.m.

08:30
a.m.

15 min

0 km

Vehicle journey Stop1

Stop3

08:30
a.m.

09:15
a.m.

45 min

30 km

Layover

Stop3

Stop3

09:15
a.m.

09:30
a.m.

15 min

0 km

Vehicle journey Stop3

Stop1

09:30
a.m.

10:15
a.m.

45 min

30 km

10

Pull-In

10:15
a.m.

10:45
a.m.

30 min

10 km

Stop1

Line

BUS1-1>

BUS1-2>

BUS1-1>

BUS1-1>

Table 190: Example line block with pull-out trip, interlining trip and pull-in trip

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 171
bottom). On the other hand, empty trips can be saved when implementing more vehicles
(illustration 171 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 564). The solution principle of line blocking in Visum, which includes creating
a graph and the solution as a flow problem, is also described here.

534

PTV AG

Chapter 7.4: Line blocking

Illustration 171: Conflict between empty trips and vehicle demand

Line blocking evaluation


The line blocking model and line blocking procedure allow you to analyze complex problems
regarding line blocks and the resulting number of vehicles required. In the following section, the
advantages of the line blocking procedure are evaluated.

PTV AG

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. There is no
maximum dwell time, as a vehicle is permitted to stay in the depot or anywhere else for any
desired period. 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 564).
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. The
non-consideration of the time required to return the vehicles would lead to an
underestimation of the empty kilometers and empty times.

535

Chapter 7: Operator model PuT

7.4.2

The duration of blocks is limited by the assignment period that can be one or several
calendar days. This allows the program to calculate the correct number of vehicles.
Minimum layover times have a major impact on possible transfers. As common in
practice, you may use minimum layover times to interpret the restrictions during the
assignment period as soft. You can thus balance the effects of minimum layover time
and vehicle deployment.
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.
You can change various parameters per block version in order to easily compare several
line blocking scenarios.
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 vehicledependent costs by means of the PuT operating indicators procedure (illustration 197).
Check line block (see "Line block check" on page 560) thus helps finding and correcting
potential errors.
Several additional issues may be considered during line blocking. This includes the
intended duration of the line blocks (number of blocking days), distribution of the layover
times, scheduling of repeated stationary events (maintenance) and the consideration of the
direction of travel.

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 "Example for PuT operating indicators" on
page 605) 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.

536

PTV AG

Chapter 7.4: Line blocking

7.4.2.1

Closed blocks according to different criteria

The first example is based on a symmetrical timetable.

Illustration 172: Line network of the example with three bus lines (red, blue and yellow)

Illustration 173: (Graphical) timetable of the example, color codes as above

PTV AG

537

Chapter 7: Operator model PuT

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.

Block no.

Block version code

Number of blocking Mean operating


days
time

Mean operating km

NoLineInterchange

1h 30min

55

NoLineInterchange

1h 30min

55

NoLineInterchange

21min

26

NoLineInterchange

56min

40

LineInterchange_Expensive 2

1h 51min

81

LineInterchange_Expensive 1

56min

40

LineInterchange_Cheap

2h 32min

111

LineInterchange_Cheap

2h 32min

111

Table 191: Block data of the three approaches

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.

538

PTV AG

Chapter 7.4: Line blocking

Illustration 174: Covering the timetable through pure line blocks


Block Index
no.

Blocking Block
day
item
type

Layover

Vehicle
journey

Layover

Vehicle
journey

Line
name

Vehicle
journey
no.

Start
time

FromStop End time ToStopPoint


Point
name
name

00:00:00
a.m.

X City

07:20:00 X City
a.m.

07:20:00
a.m.

X City

08:05:00 A Village
a.m.

08:05:00
a.m.

A Village

08:40:00 A Village
a.m.

08:40:00
a.m.

A Village

09:25:00 X City
a.m.

Layover

09:25:00
a.m.

X City

00:00:00 X City
a.m.

Layover

00:00:00
a.m.

A Village

06:59:00 A Village
a.m.

Vehicle
journey

07:10:00
a.m.

A Village

07:55:00 X City
a.m.

Layover

07:55:00
a.m.

X City

08:50:00 X City
a.m.

Vehicle
journey

08:50:00
a.m.

X City

09:35:00 A Village
a.m.

BUS1

BUS1

BUS1

BUS1

Table 192: Block items of the line blocks in block version 1

PTV AG

539

Chapter 7: Operator model PuT

Block Index
no.

Blocking Block
day
item
type

Line
name

Vehicle
journey
no.

Start
time

FromStop End time ToStopPoint


Point
name
name

Layover

09:35:00
a.m.

A Village

00:00:00 A Village
a.m.

Layover

00:00:00
a.m.

X City

08:05:00 X City
a.m.

Vehicle
journey

22

08:05:00
a.m.

X City

08:26:00 A Village
a.m.

Layover

08:26:00
a.m.

A Village

00:00:00 A Village
a.m.

Layover

00:00:00
a.m.

A Village

08:15:00 A Village
a.m.

Vehicle
journey

21

08:15:00
a.m.

A Village

08:36:00 X City
a.m.

Layover

08:36:00
a.m.

X City

00:00:00 X City
a.m.

Layover

00:00:00
a.m.

A Village

06:25:00 A Village
a.m.

Vehicle
journey

31

06:25:00
a.m.

A Village

06:53:00 B Village
a.m.

Layover

06:53:00
a.m.

B Village

10:00:00 B Village
a.m.

Vehicle
journey

32

10:00:00
a.m.

B Village

10:28:00 A Village
a.m.

Layover

10:28:00
a.m.

A Village

00:00:00 A Village
a.m.

BUS2

BUS2

BUS3

BUS3

Table 192: Block items of the line blocks in block version 1

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.

540

PTV AG

Chapter 7.4: Line blocking

Illustration 175: Covering the timetable through blocks without empty trips
Block Index
no.

Blocking Block
Line
day
item type name

Vehicle
journey
no.

Start
time

Layover

00:00:00 A Village
a.m.

06:25:00 A Village
a.m.

Vehicle
journey

07:10:00 A Village
a.m.

07:55:00 X City
a.m.

Layover

07:55:00 X City
a.m.

08:05:00 X City
a.m.

Vehicle
journey

22

08:05:00 X City
a.m.

08:26:00 A Village
a.m.

Layover

08:26:00 A Village
a.m.

08:40:00 A Village
a.m.

Vehicle
journey

08:40:00 A Village
a.m.

09:25:00 X City
a.m.

Layover

09:25:00 X City
a.m.

00:00:00 X City
a.m.

Layover

00:00:00 X City
a.m.

07:20:00 X City
a.m.

BUS1

BUS2

BUS1

FromStop End time ToStopPoint


Point
name
name

Table 193: Block items of the line blocks in block version 2

PTV AG

541

Chapter 7: Operator model PuT

Block Index
no.

Blocking Block
Line
day
item type name

Vehicle
journey
no.

Start
time

Vehicle
journey

07:20:00 X City
a.m.

08:05:00 A Village
a.m.

10

Layover

08:05:00 A Village
a.m.

08:15:00 A Village
a.m.

11

Vehicle
journey

21

08:15:00 A Village
a.m.

08:36:00 X City
a.m.

12

Layover

08:36:00 X City
a.m.

08:50:00 X City
a.m.

13

Vehicle
journey

08:50:00 X City
a.m.

09:35:00 A Village
a.m.

14

Layover

09:35:00 A Village
a.m.

00:00:00 A Village
a.m.

Layover

00:00:00 A Village
a.m.

06:25:00 A Village
a.m.

Vehicle
journey

31

06:25:00 A Village
a.m.

06:53:00 B Village
a.m.

Layover

06:53:00 B Village
a.m.

10:00:00 B Village
a.m.

Vehicle
journey

32

10:00:00 B Village
a.m.

10:28:00 A Village
a.m.

Layover

10:28:00 A Village
a.m.

00:00:00 A Village
a.m.

BUS1

BUS2

BUS1

BUS3

BUS3

FromStop End time ToStopPoint


Point
name
name

Table 193: Block items of the line blocks in block version 2

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 vehicle journeys running at the same
time.

542

PTV AG

Chapter 7.4: Line blocking

Illustration 176: Covering the timetable through line comprehensive blocks with empty trips

Note: The empty trips in illustration 176 run 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 Index
no.

Blocking Block
day
item
type

Layover

Vehicle
journey

Layover

Vehicle
journey

Layover

Vehicle
journey

Line
name

BUS1

BUS2

BUS1

Vehicle Start time FromStop End time


journey
Point
name

ToStopPoint
name

00:00:00
a.m.

A Village

06:25:00
a.m.

A Village

07:10:00
a.m.

A Village

07:55:00
a.m.

X City

07:55:00
a.m.

X City

08:05:00
a.m.

X City

22

08:05:00
a.m.

X City

08:26:00
a.m.

A Village

08:26:00
a.m.

A Village

08:40:00
a.m.

A Village

08:40:00
a.m.

A Village

09:25:00
a.m.

X City

Table 194: Block items of the line blocks in block version 3

PTV AG

543

Chapter 7: Operator model PuT

Block Index
no.

Blocking Block
day
item
type

Line
name

Vehicle Start time FromStop End time


journey
Point
name

ToStopPoint
name

Empty
trip

09:25:00
a.m.

X City

09:38:00
a.m.

B Village

Layover

09:38:00
a.m.

B Village

10:00:00
a.m.

B Village

Vehicle
journey

32

10:00:00
a.m.

B Village

10:28:00
a.m.

A Village

10

Layover

10:28:00
a.m.

A Village

00:00:00
a.m.

A Village

Layover

00:00:00
a.m.

A Village

06:25:00
a.m.

A Village

Vehicle
journey

31

06:25:00
a.m.

A Village

06:53:00
a.m.

B Village

Empty
trip

06:53:00
a.m.

B Village

07:06:00
a.m.

X City

Layover

07:06:00
a.m.

X City

07:20:00
a.m.

X City

Vehicle
journey

07:20:00
a.m.

X City

08:05:00
a.m.

A Village

Layover

08:05:00
a.m.

A Village

08:15:00
a.m.

A Village

Vehicle
journey

21

08:15:00
a.m.

A Village

08:36:00
a.m.

X City

Layover

08:36:00
a.m.

X City

08:50:00
a.m.

X City

Vehicle
journey

08:50:00
a.m.

X City

09:35:00
a.m.

A Village

10

Layover

09:35:00
a.m.

A Village

00:00:00
a.m.

A Village

BUS3

BUS3

BUS1

BUS2

BUS1

Table 194: Block items of the line blocks in block version 3

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.

544

PTV AG

Chapter 7.4: Line blocking

Illustration 177: 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 vehicle journey 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.

PTV AG

545

Chapter 7: Operator model PuT

Block no.

Block version code

Number of
blocking
days

Block closed Mean operating


time

Mean operating km

OpenBlocks

12h 51min

616

Self-ContainedBlocks 2

6h 36min

321

Table 195: Open block and closed block for the unsymmetrical example (illustration 177)
Block Index Blocking Block item Line
no.
day
type
name

Vehicle
journey
no.

Start
time

Vehicle
journey

16

03:05:00 A Village
a.m.

03:50:00 X City
a.m.

Empty trip

03:50:00 X City
a.m.

04:11:00 A Village
a.m.

Layover

04:11:00 A Village
a.m.

05:05:00 A Village
a.m.

Vehicle
journey

18

05:05:00 A Village
a.m.

05:50:00 X City
a.m.

Empty trip

05:50:00 X City
a.m.

06:11:00 A Village
a.m.

Layover

06:11:00 A Village
a.m.

07:05:00 A Village
a.m.

...

...

...

...

...

...

...

...

31

Vehicle
journey

BUS1

36

11:05:00 A Village
p.m.

11:50:00 X City
p.m.

32

Empty trip

11:50:00 X City
p.m.

00:11:00 A Village
a.m.

33

Layover

00:11:00 A Village
a.m.

02:05:00 A Village
a.m.

34

Vehicle
journey

37

02:05:00 A Village
a.m.

02:50:00 X City
a.m.

Layover

00:11:00 A Village
a.m.

02:05:00 A Village
a.m.

Vehicle
journey

37

02:05:00 A Village
a.m.

02:50:00 X City
a.m.

Empty trip

02:50:00 X City
a.m.

03:11:00 A Village
a.m.

Layover

03:11:00 A Village
a.m.

00:00:00 A Village
a.m.

Layover

00:00:00 A Village
a.m.

03:05:00 A Village
a.m.

BUS1

BUS1

BUS1

BUS1

FromStop
Point
name

...

End time ToStopPoint


name

...

Table 196: 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.

546

PTV AG

Chapter 7.4: Line blocking

Block Index Blocking Block item Line


no.
day
type
name

Vehicle
journey
no.

Start
time

Vehicle
journey

16

03:05:00 A Village
a.m.

03:50:00 X City

Empty trip

03:50:00 X City
a.m.

04:11:00 A Village
a.m.

Layover

04:11:00 A Village
a.m.

05:05:00 A Village
a.m.

Vehicle
journey

18

05:05:00 A Village
a.m.

05:50:00 X City
a.m.

10

Empty trip

05:50:00 X City
a.m.

06:11:00 A Village
a.m.

11

Layover

06:11:00 A Village
a.m.

07:05:00 A Village
a.m.

...

...

...

...

...

...

...

...

36

Vehicle
journey

BUS1

36

11:05:00 A Village
p.m.

11:50:00 X City
p.m.

37

Empty trip

11:50:00 X City
p.m.

00:11:00 A Village
a.m.

BUS1

BUS1

FromStop
Point
name

...

End time ToStopPoint


name

...

Table 196: 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.

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 stop points
Line block check
Coverage check

7.4.3.1

Block version

In Visum multiple line blocking results can be stored in parallel. 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 197.

PTV AG

547

Chapter 7: Operator model PuT

Attribute

Description

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.

Interlining permissible

Specifies, whether the line blocking and check line block procedures
should create empty trips (see "Line block check" on page 560).

System routes application

Specifies, whether system routes should be used for generating empty


trips.

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 prepreparation 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 197: Block version attributes

548

PTV AG

Chapter 7.4: Line blocking

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 does neither depend on the line blocking time
interval nor on the length of the calendar. The attribute Number of blocking days reflects the
vehicle demand which arises for a block. In illustration 178, 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.

Illustration 178: Blocking days and vehicle demand

A block possesses the attributes described in table 198.


Attribute

Description

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 Specifies which transport system should be used within check line block
code
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 "Line
block check" on page 560).

Has layover time fault

Specifies, whether pre- and post-preparation times were exceeded (see


"Line block check" on page 560).

Table 198: Block attributes

PTV AG

549

Chapter 7: Operator model PuT

Attribute

Description

Has blocking day fault

Specifies, whether a blocking day without block items exists (see "Line
block check" on page 560).

Has time fault

Specifies, whether a time fault exists (see "Line block check" on page 560).

Has location fault

Specifies, whether a location fault exists (see "Line block check" on


page 560).

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 "Line block
check" on page 560).

Has forced chaining errors

Specifies, whether a valid forced chaining which was not adhered to, exists
(see "Line block check" on page 560).

Has running direction fault

Specifies, whether a running direction fault exists (see "Line block check"
on page 560).

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.

Regard running direction

Specifies, whether the running direction is relevant for the check of this line
block. Otherwise, the line block check cannot detect a running direction
fault. If the running direction is not relevant (buses, for example), this
portion of the line block check can be disabled via this option (see "Line
block check" on page 560).

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.

Start time

Start time of the block, therefore start time of the first block item. For closed
blocks this is usually midnight, unless a vehicle journey block item exceeds
24 hours on the last day.

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.

End time

Ending time of the block, therefore end time of the last block item. For
closed blocks this is usually midnight, unless a vehicle journey block item
exceeds 24 hours on the last day.

Empty trip time

Cumulative time, which is accumulated by empty trips and user-defined


block item types of the block.

Empty time

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)

Table 198: Block attributes

550

PTV AG

Chapter 7.4: Line blocking

Attribute

Description

Mean empty trip time

Empty trip time / (Number of blocking days Number of line blocking time interval
days)

Empty kilometers / miles

Cumulative distance, which is covered by empty trips and user-defined


block item types of the block.

Mean empty kilometers /


miles

Empty kilometers / (Number of blocking days Number of line blocking time


interval days)

Out-of-depot 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 /
miles

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
miles
interval days)
Service time

Sum of run times of the vehicle journeys of a block.

Mean service time

Service time / (Number of blocking days Number of line blocking time interval
days)

Time outside depot

Block time minus time in depot

Mean time outside depot

Time outside depot / (Number of blocking days Number of line blocking time
interval days)

Service kilometers / miles

Sum of the length of all vehicle journey block items of a block.

Mean service kilometers /


miles

Service kilometers / (Number of blocking days Number of line blocking time


interval days)

Block time

Total block time.


Number of days in the line blocking time interval Number of blocking 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 vehicle journey block times, which are run by the block.

Cost distance

Kilometer costs of the block, which result from the traversed service and
empty kilometers (illustration 197).

Cost vehicle

Vehicle costs, which result from the number of required vehicles and the
fixed costs for a vehicle unit (illustration 197).

Cost vehicle referring to the Cost vehicle projected to the line blocking time interval
line blocking time interval
Cost Time

Hourly costs, which result from the time required for vehicle journeys and
empty trips.

Cost time with layover

Hourly block costs which arise from the vehicle journeys and empty trips, as
well as from downtimes within or outside of a depot accumulated time
periods.

Table 198: Block attributes

PTV AG

551

Chapter 7: Operator model PuT

Attribute

Description

Leading depot number

Depot with the longest dwell time. For ambiguity, the depot with the
smallest number.

Table 198: Block attributes

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. The table 199 shows the attributes of a
block item and their meanings.
Attribute

Description

Blocking day

Specifies, to which blocking day the block item has been assigned.

Block item type number / Number and name of the block item type of the block item. By default, the four
name
block item types vehicle journey, empty trip, layover time and depot are
defined.
Line name

Line which is run by this block item. The attribute only displays a value, if the
block item is a vehicle journey.

Line route name

Line route which is traversed by this block item. The attribute only displays a
value, if the block item is a vehicle journey.

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 vehicle journey.

Time profile name

Time profile which is used by this block item. The attribute only displays a
value, if the block item is a vehicle journey.

Vehicle journey number

Vehicle journey which is run by this block item. The attribute only displays a
value, if the block item is a vehicle journey.

Vehicle journey section


number

Vehicle journey section which is traversed by this block item. The attribute
only displays a value, if the block item is a vehicle journey.

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).

Start time

Start of the block item

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).

End time

End of the block item

From stop point number / Stop point where the block item starts. Complies with To stop point, if it is a
name
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.

Table 199: Block item attributes

552

PTV AG

Chapter 7.4: Line blocking

Attribute

Description

Length

Distance of the block item. 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

Distance 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

Period 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.

Starts in forward
direction

Specifies whether the activity starts in forward direction or in reverse direction.


The attribute is set during the line block check, if the running direction of the
line block is taken into account.

Is change of running
direction

Specifies whether the activity which is described by this line block item
includes a change of the running direction. Is only regarded for user-defined
line block items.

Table 199: Block item attributes

Each block item is of a certain type (block item type). By default, there are the block item types
vehicle journey, empty trip, stand (layover/depot) 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). The table 200 shows the attributes of block item types.
Attribute

Description

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 function
will return a limit fault (see "Line block check" on page 560).

Table 200: Block item type attributes

PTV AG

553

Chapter 7: Operator model PuT

Attribute

Description

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 line block check will return a limit fault (see "Line block check" on
page 560).

Table 200: Block item type attributes

7.4.3.4

Attributes of the line blocking cost function

To find the optimum line block, a cost function is minimized during line blocking (see "Line
blocking description without vehicle interchange" on page 563). The attributes found in
table 201 are regarded by this cost function.
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 (= Total number of vehicles required for the block version.
vehicle journey, layover
in depot, layover at
stop point, pre and post
preparation time,
empty trip)

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.

Service time

Activity

Service time which accumulates during the activity.

Cost Rate Service


Hour Total

Vehicle combination

Costs which accumulate for a service hour of the


vehicle combination.

Service kilometers

Activity

Service kilometers which accumulate during the


activity.

Cost Rate Service km Vehicle combination


/ mi Total

Costs which accumulate for a mileaged service


kilometer/mile of the vehicle combination.

Empty time

Activity

Empty time which accumulates during the activity.

Cost Rate Empty


Hour Total

Vehicle combination

Costs which accumulate for an empty hour of the


vehicle combination.

Empty kilometers

Activity

Empty kilometers which accumulate during the activity.

Table 201: Attributes of the line blocking cost function

554

PTV AG

Chapter 7.4: Line blocking

Attribute

Object

Description

Cost Rate Empty km / Vehicle combination


mi Total

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 Vehicle combination


Total

Costs which accumulate for a layover hour of the


vehicle combination in a depot.

Table 201: Attributes of the line blocking cost function

7.4.3.5

Downtimes in depots and at stop points

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.
Attribute

Description

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.

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
vehicle combination.

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
vehicle combination.

Table 202: Depot attributes of stop points

PTV AG

555

Chapter 7: Operator model PuT

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 203: Cost rates for downtimes at depots and stop points at vehicle unit (cost rates in table 201 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 204: Cost rates for downtimes at depots and stop points at the vehicle combination (cost rates in
table 201 refer to this)

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 with regard to the empty trip transport system of
the block. For the line block check, this is the specified empty trip transport system (input
attribute). No blocks exist a priori for line blocking. Dependent on the parameter settings for
each configuration (see "Partitioning" on page 563) 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 block version attribute Use system routes it can be specified further, how the empty
trip calculation should be carried out:

556

Do not use system routes


Empty trips are generated through shortest path search for the empty trip transport system
in the network. The shortest paths in terms of distance or run time (t_PuTSys) are
calculated, for example.

PTV AG

Chapter 7.4: Line blocking

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.
Create system routes, if required
Actually, the computation rules for the 'Use system routes' option apply. If no matching
system route can be found for an empty trip, the successful shortest path search will create
a new system route for this pair of stop points. The empty trip will use this information. The
resulting 'empty trip' block item has a relation to the generated system route.

With the selection of the suitable option, the generated empty trips can be controlled in detail.

7.4.3.7

Regard running direction

In many cases, the running direction of a vehicle carrying out a vehicle journey does not have
to be regarded separately. This is the case if all vehicle journeys are carried out in the 'ahead'
mode (one-way vehicle, especially all buses and some trams) or if the running direction is
irrelevant (railcar operation in rapid transit). Anyhow, in some cases it is requested, that the
running direction of the vehicle combination is always the same, for example, because the
station wagon of a train is expected to stop at a fixed position at the platform or because the
vehicle dynamics of push-pull trains depends on the running direction.
Thus it is optionally possible to take the running direction into account for line block checks and
manual line blocking Visum. For this purpose, for each turn in the network it has to be specified
if this turn means a change of the running direction. Useful data can be provided by turn
standards (see "Nodes and turns" on page 37) based of turn types.
Thus, each movement in the network inherits information on running direction changes. Along
a line route which means in the course of a vehicle journey a running direction change occurs
especially where a turn with the property Is change of running direction is traversed. If a line
block takes the running direction into account (attribute Regard running direction), these
changes of the running direction will be visualized in the line block display.

PTV AG

557

Chapter 7: Operator model PuT

Illustration 179: Display of a change of the running direction in the course of vehicle journey block items.
The line route makes a U-turn in the station "TFS"

Accordingly, the empty trip block items obtain information from the network whether running
direction changes occur in their course. If the empty trip is based on a system route, the
running direction changes are located in the same manner as for vehicle journeys and will
similarly be visualized in the line block display. If there is no system route, then the route
search determines whether an even or an odd number of direction changes appears; only this
is relevant to line blocking. Thus, empty trip block items with an odd number of running
direction changes are centre-subdivided in the view.
For user-defined block items the information whether running direction changes are included is
explicitly stored with the attribute Is change of running direction. Hence, also a rotary
journey (U-turn or triangle-shaped) can explicitly be modeled as user-defined block item.
If the running direction has to be regarded for a line block, the line block check will verify the
item end - item start changeovers in the sequence of line block items and define the running
direction at the beginning of the activity for each block item. A direction fault is recorded if a
vehicle journey section is run in either direction by this line block on different calendar days. For
a closed line block, a direction fault is additionally recorded if the running direction changes
after the closed line block has been completed.
The line blocking procedure cannot directly evaluate the change of running direction
information. Thus it cannot intentionally generate line blocks without direction faults. In the line
blocking procedure, the parameter Regard running direction works as follows:

558

PTV AG

Chapter 7.4: Line blocking

Regard running direction: Subsequently to the line blocking procedure, the line blocks are
checked for direction faults. If applicable, the appropriate fault status is set.
Do not regard running direction: For the line blocks, the attribute Regard running
direction is set to 'false'.

Attribute

Description

Is change of running
direction

If attribute default values from the turn standard are allocated to a turn, the
original turn attribute values will be replaced by the allocated standard values for
the selected attributes. This makes the standard value allocation easier. To all
turns of the U-turn type, for example, the property Is change of running
direction can be allocated.

Table 205: Turn standard attributes with reference to running directions


Attribute

Description

Is change of running
direction

The value of this attribute indicates, whether traversing this turn means a
change of the running direction. This applies to line routes and system routes as
well as to the change of direction determination for empty trips during the line
block check. Furthermore, this attribute is evaluated for the item end - item start
changeovers in the sequence of line block items within a line block.

Table 206: Turn attributes with reference to running directions


Attribute

Description

Is change of running
direction

Is true, if the line route item is located at a node, where the line route course
traverses a turn with the property Is change of running direction.

Table 207: Line route attributes with reference to running directions

7.4.3.8

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

PTV AG

559

Chapter 7: Operator model PuT

respective vehicle combination sets have a non-empty intersection (block has vehicle
interchange).
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 vehicle journey block items.

7.4.3.9

Line block check

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 vehicle
journeys). 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 eight error flags.
The state model in illustration 180 shows the possible states of a block and how the eight flags
are set.

560

PTV AG

Chapter 7.4: Line blocking

Line
Blocking

New Block

Unchecked

No Fault

Block
Check

Veh. Fault

Empty Day Fault

Limit Fault

Direction Fault

Minor Faults
Layover Time Fault
Forced Chaining Fault

Adjustment to
altered data

Adjustment to
altered data

Adjustment to
altered data

all minor faults

Major Faults
Time Fault

Location
Fault

Adjustment to
altered data

Edit Block
Illustration 180: State model for line 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.

PTV AG

Location fault
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.
Time fault
Two successive trips in a block overlap with regard to time. This means, that the preceding
trip arrives later than the successive trip departs.
Layover time fault
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.
Vehicle fault
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 comparison regards either vehicle journey section
attribute vehicle combination or vehicle combination set.

561

Chapter 7: Operator model PuT

Blocking day fault (EmptyDayFault)


If there is an empty blocking day, this error is set. This means, that there is a blocking day
without a block item on any calendar day (except for layover items). In this case, an extra
vehicle has unnecessarily been planned.
Limit fault
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.
Forced chaining fault
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.
Direction fault
The line block includes a vehicle journey section which either is passed in the opposite
direction on a different day, or the vehicle's direction of travel changes after a closed line
block has been completed. The direction fault check is only performed, if the line block
attribute Regard running direction is true.

A block that contains the flag unchecked or time fault or location fault is not allowed to be
regarded by subsequent evaluations (for example in the PuT operating indicators procedure).
The other six 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 581), which often contain such errors (partially
deliberately).

Common line block check and forced line block check


Between the network basis and blocks, two types of inconsistencies can occur through
subsequent changes, which are not found in common checks of 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 1164). These are the two inconsistencies in detail:

562

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 postpreparation 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 userdefined 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.

PTV AG

Chapter 7.4: Line blocking

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.

7.4.3.10 Coverage check


For a block version it can be determined, whether the version covers all vehicle journey
sections in a given time frame (from day - to day, i.e. the analysis period, generally) (see User
Manual, Chpt. 7.1.1.4, page 1163). If there is a vehicle journey section which is - for a calendar
day - not bound by a vehicle journey 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 calculate line blocking with vehicle interchange (see "Line
blocking description with vehicle interchange" on page 573).
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 1169). Prior to the graph construction, the problem is broken down into subproblems, socalled 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.

PTV AG

563

Chapter 7: Operator model PuT

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 1169). 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. The illustration 181 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 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.
VehComb

Articulated Bus

Standard Bus

Tram

Operator

Operator1

Operator 2

Operator 1

Operator 2

Operator 1

Graph

Graph 1

Graph 2

Graph 3

Graph 4

Graph 5

Illustration 181: Example for partitioning according to vehicle combination and operator

Note: Capacity restrictions in depots can only be considered, if the graph is not partitioned
further than by 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.

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. Below, these nodes are called 'real events'. Departure and arrival in each case is
the time including possible pre- and post-preparation times, if these are taken into
consideration (see User Manual, Chpt. 7.1.3.2, page 1169).

564

PTV AG

Chapter 7.4: Line blocking

"real" arrival or departure event

vehicle journey section

depot ( = C)
time

Illustration 182: 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.

PTV AG

565

Chapter 7: Operator model PuT

"real" arrival or departure event


"fake" arrival or departure event

vehicle journey section


trip to depot

empty trip between stop points

depot ( = C)
time

Illustration 183: 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).

566

PTV AG

Chapter 7.4: Line blocking

"real" arrival or departure event

vehicle journey

trip from depot


trip to depot

empty trip between stoo points

"fake" arrival or departure event

depot ( = C)
time

Illustration 184: Inserting the edges for leaving from depots

Note: If interlining is prohibited (see User Manual, Chpt. 7.1.3.2, page 1169), 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.
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. Vehicle journey 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 544) you can find
a note concerning open and closed line blocks.

PTV AG

567

Chapter 7: Operator model PuT

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 185.
"real" arrival or departure event

vehicle journey

trip from depot


trip to depot

empty trip between stop points

"fake" arrival or departure event

timeline edge

depot ( = C)
time

Illustration 185: 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 481). 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:

568

PTV AG

Chapter 7.4: Line blocking

Cost

= Required vehicles Coefficient Cost rate vehicle unit total


+ Service time Coefficient Cost rate hour service
+ ServiceKm/Mi Coefficient Cost rate Km/Mi service
+ Space Coefficient Cost rate hour empty
+ EmptyKm/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".
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.

Vehicle journey 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, vehicle
journey edges are still evaluated with the vehicle journey cost rates of the vehicle
combination for duration and distance.)
ServiceKm/Mi describes the distance covered by the vehicle journey
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
departure from the FromNode plus the duration between the arrival at the ToNode and
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
departure from the FromNode plus the duration between the arrival at the ToNode and
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.

PTV AG

569

Chapter 7: Operator model PuT

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
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.
The illustration 186 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.
"real" arrival or departure event

vehicle journey section

trip from depot

"fake" arrival or departure event

empty trip between stop points

trip to depot

evaluation line

optimum flow

timeline edge

depot ( = C)
time

Illustration 186: 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.

570

PTV AG

Chapter 7.4: Line blocking

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. The
illustration 187 and the illustration 188 show two possible examples, how the cost-efficient flow
can be decomposed into blocks.
"real" arrival or departure event

block 1

trip from depot

vehicle journey

trip to depot

empty trip between stop points

"fake" arrival or departure event


block 2

block 3

timeline edge

depot ( = C)
time

Illustration 187: Example 1 for the decomposition into blocks

PTV AG

571

Chapter 7: Operator model PuT

"real" arrival or departure event

block 1

trip from depot

vehicle journey

trip to depot

empty trip between stop points

"fake" arrival or departure event


block 2

block 3

timeline edge

depot ( = C)
time

Illustration 188: 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:

572

The structure of the changeovers 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.
Even blocks: For assignment periods of more than one day, the program aims at
calculating line blocks that look as similar as possible for all calendar days.
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 vehicle journeys of a partition are covered by a single line block.
Preferably, build short blocks: Blocks have as few blocking days as possible.

PTV AG

Chapter 7.4: Line blocking

7.4.5

No specific requirements: In this dimension, no requirements are set concerning the


result.

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 on
the 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 563) and also covers the following application areas.

Planning the vehicle use depending on the demand, at the same time considering blockrelated 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.
Consideration of different vehicle combination-specific minimum layover times

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 includes 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.

PTV AG

573

Chapter 7: Operator model PuT

Because the line blocking is carried out as in the procedure without vehicle interchange (see
"Line blocking description without vehicle interchange" on page 563), for defined selection of
the vehicle combinations, the following additional components are necessary to understand
the procedure:

Selection principles of vehicle combinations


Solution evaluation via objective function
Parameters and convergence
Consideration of different vehicle combination-specific minimum layover times

7.4.5.1

Selection principles of vehicle combinations

The selection of vehicle combinations which can be used from the set specified for each
vehicle journey section, 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:

574

For an individual occurrence of a vehicle journey section the selection is carried out
randomly
according to the volume of the vehicle journey 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 vehicle journey 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 vehicle journeys 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.

PTV AG

Chapter 7.4: Line blocking

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:

Replace empty trips of a vehicle combination, so that for this vehicle combination a suitable
temporal and local vehicle journey 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 564) 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:
OF =

c i of i
------------------------------------------------i c comparison
j
i
j

where

PTV AG

575

Chapter 7: Operator model PuT

ci

Influential factor (Procedure parameters) for the indicator i, where ci > 0

ofi

Objective function component for indicator i according to the upper list

comparisoni

Comparison value for indicator i on a comparable scale

The individual component properties are apply as follows:


Component

Calculation

Cost

The objective function component costs evaluate the solution according to the
same criteria as the line blocking without vehicle interchange.
It therefore applies

ofCosts = fe Costs(e) (fe = 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 comparisonvehicle is 1 (Note: This is how you achieve very
strong penalization, because this criterion must apply "strongly", if it is even used)

Consideration of
volumes

For the calculation, for each vehicle journey item i first the difference between its
volume and its capacity (cap) is calculated as follows

volVJI ( cap factor vc ) ,volVJI ( cap factor vc ) > 0 and VJI is active
i =
volVJI ( cap factor vc ),vol VJI ( cap factor vc ) 0 , else

where factor vc target saturation factor


The capacity sums up from the selected capacity (seats or total) of all vehicle
combinations of all vehicle journey sections that service this vehicle journey item.
Due to the current parameter settings, a vehicle journey's value x vol results from
the particular formula below:
using option Average volume

i
x vol = ---------------------------------------------------------------------------------------
number of VJI of the vehicle journey
using option Peak volume

i
x vol = -------------------------------------------------------
max of i over all VJI
The value of volume is the total calculated for all vehicle journeys:

of volume =

xvol
VJ

The value of this objective function component, which applies for the random
solution, used for cost estimation, is used as a comparison value.

Table 208: Objective function components for line blocking with vehicle interchange

576

PTV AG

Chapter 7.4: Line blocking

Component

Calculation

Line purity, local


definition

The number of line changes between successive vehicle journeys in the block are
measured. The benchmark is the number of occurrences of vehicle journey
sections in total (therefore the number of all changeovers between successive
vehicle journey block 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.
The following applies:
ofregularity = Sum of vehicle journey sections |{Blocks / blocking days which contain
the VJS}| - 1
comparisonregularity = (Sum of occurrences of the VJS in the line blocking time
interval 1)

Distance to
starting solution

The number of changeovers from vehicle journey section to vehicle journey section,
which differ from the comparison solution, is measured.
The comparison value is the number of all changeovers from vehicle journey
section to vehicle journey section in the comparison solution.

Table 208: 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.

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:

PTV AG

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.

577

Chapter 7: Operator model PuT

Parameters

Meaning and notes

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, however, they should not be less than 10 - 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.

7.4.5.4

Consideration of different vehicle combination-specific


minimum layover times

Between two vehicle journeys, different vehicles require efforts of a different extent. There are
various reasons:

Changing the running direction for a long train requires more time than changing it for a
short train. This is because it takes longer to get to the other driver's cabin at the end of the
train.
The length in time required by boarding and alighting passengers at scheduled stops
depends on the configuration of the vehicle doors.
Various final and cleaning services are required, also supply and disposal services.

Due to the various minimum layover times of different vehicle combinations, certain
changeovers between vehicle journeys are only possible for some of the provided vehicle
combinations, whereas the time slot is insufficient for others. Thus, these differences should be
regarded for the efficient vehicle use, and a vehicle should be chosen where it can be used
best.
Line blocking with vehicle interchange can take the different minimum layover times into
account. For that purpose, the attributes Use specific pre preparation time and Use specific
post preparation time have to be set to true for the concerned vehicle journey sections. Then,
via the attributes Specific pre preparation time und Specific post preparation time - each
with sub-attribute vehicle combination - the values for the pre and post preparation times can
be set for each vehicle combination. This data is automatically regarded by the procedure line
blocking with vehicle interchange. Even the line block check will take the different pre and post
preparation time values into account for the vehicle combination of the line block which will
then be determined.

7.4.6

Line block display and editing in the timetable editor


In Visum blocks are displayed 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

578

PTV AG

Chapter 7.4: Line blocking

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.

Illustration 189: Example for block display of a block with 5 blocking days

The line block display is included in the timetable editor. There you can find detailed
information on display and editing (see User Manual, Chpt. 7.1.5, page 1183).

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 returned in the length proportional and in the time proportional
mode. 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.

PTV AG

Vehicle journeys
Time profiles
Line routes
Lines
Main lines
Operators
Transport systems
Territories
Territory PuT detail

579

Chapter 7: Operator model PuT

Indicator

Description

Number of Vehicles
(in proportion to
length)

Length of the vehicle journey section divided by the total length of all vehicle
journey block items in the block, multiplied by the number of blocking days of the
block.

Number of vehicles
(in proportion to
time)

Length of the vehicle journey section divided by the total length of all vehicle
journey block items in the block, multiplied by the number of blocking days of the
block.

Table 209: Line blocking and vehicle requirement indicators

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 lengthoriented 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.

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.

7.4.7.2

Distribution of empty trips and empty times to vehicle


journeys

As line costing is based on vehicle journeys, empty times and empty kilometers of a line block
have to be allocated to the vehicle journeys 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

Variant 1: EmptyTime from Pre+PostPrepTime (2+3 min) of veh. journey / no EmptyKm

580

Vehicle journey

ServTime

Empty time OpTime

ServKm

EmptyKm

OpKm

1st

6:30 7:15

0:45:00

0:05:00

0.50

30 km

0 km

30 km

2nd

8:00 8:15

0:15:00

0:05:00

0.20

10 km

0 km

10 km

PTV AG

Chapter 7.4: Line blocking

3rd

8:30 9:15

0:45:00

0:05:00

0.50

30 km

0 km

30 km

4th

9:30 10:15

0:45:00

0:05:00

0.50

30 km

0 km

30 km

2:30:00

0.20

2:50:00

100 km

0 km

100 km

Total

Variant 2: From EmptyTime/EmptyKm of line block weighted by vehicle journeys


Vehicle journey

ServTime

Empty time OpTime

ServKm

EmptyKm

OpKm

1st

6:30 7:15

0:45:00

0:33:45

1:18:45

30 km

7.5 km

37.5 km

2nd

8:00 8:15

0:15:00

0:33:45

0:48:45

10 km

7.5 km

37.5 km

3rd

8:30 9:15

0:45:00

0:33:45

1:18:45

30 km

7.5 km

37.5 km

4th

9:30 10:15

0:45:00

0:33:45

1:18:45

30 km

7.5 km

37.5 km

2:30:00

2:15:00

4:45:00

100 km

30 km

130 km

Sum

Variant 3: From EmptyTime/EmptyKm of line block weighted by service time


Vehicle journey

ServTime

Empty time OpTime

ServKm

EmptyKm

OpKm

1st

6:30 7:15

0:45:00

0:40:30

30 km

9 km

39 km

2nd

8:00 8:15

0:15:00

0:13:30

0:28:30

10 km

3 km

13 km

3rd

8:30 9:15

0:45:00

0:40:30

1:25:30

30 km

9 km

39 km

4th

9:30 10:15

Sum

1:25:30

0:45:00

0:40:30

1:25:30

30 km

9 km

39 km

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 vehicle journey


Vehicle journey

ServTime

Empty time OpTime

ServKm

EmptyKm

OpKm

1st

6:30 7:15

0:45:00

0:52:30

1:37:30

30 km

15 km

45 km

2nd

8:00 8:15

0:15:00

0:30:00

0:45:00

10 km

5 km

15 km

3rd

8:30 9:15

0:45:00

0:15:00

1:00:00

30 km

0 km

30 km

4th

9:30 10:15

0:45:00

0:37:30

1:22:30

30 km

10 km

40 km

2:30:00

2:15:00

4:45:00

100 km

30 km

130 km

Summe

Table 210: Example illustrating different variants of distribution of empty time and empty kilometers on
individual vehicle journeys.

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 vehicle journey 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

PTV AG

581

Chapter 7: Operator model PuT

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.
In the line blocking procedure (see User Manual, Chpt. 7.1.3, page 1168), 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.
The table 211 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.
SP20

SP21

SP22

SP24

SP50

SP56

SP71

SP74

SP86

SP20

16

36

61

34

73

121

108

999999

SP21

16

20

45

50

89

137

124

999999

SP22

36

20

25

70

109

157

144

999999

SP24

61

45

25

95

134

182

169

999999

SP50

34

50

70

95

39

87

74

999999

SP56

73

89

109

134

39

48

35

999999

SP71

999999

999999

999999

999999

999999

999999

999999

999999

SP74

108

124

144

169

74

35

13

999999

SP86

121

137

157

182

87

48

999999

13

Table 211: PuT interlining matrix with t-PuTSys between stop points

7.5

PuT fare model


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 586).

582

PTV AG

Chapter 7.5: PuT fare model

The illustration 190 offers an overview of the network objects which belong to the fare modeling
in Visum.

Illustration 190: Possibilities of fare modeling in Visum

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
however model, that a change between fare systems costs extra or a reduction is given (see
"Transport system-specific supplements" on page 591).

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.

PTV AG

583

Chapter 7: Operator model PuT

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
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 600).
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.
584

PTV AG

Chapter 7.5: PuT fare model

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.

Subjects

7.5.1

Ticket types
Fare systems
Fare calculation
Application of fares

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 595). 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 and 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

Transport systemspecific
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.

Essential characteristic of a ticket type is the fare structure, which defines the calculation
method for the base fare:

PTV AG

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.

585

Chapter 7: Operator model PuT

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 to connections, which lie outside of the considered fare zones.
Both the from-to zone-based fares, as well as distance-based fares may refer to certain pairs
of fare zones only or certain distance classes.
The rank defines the ticket type hierarchy within a fare system and is relevant if a fare system
comprises several ticket types. The definition of the rank is illustrated by several examples (see
"Ticket selection in a fare system" on page 597).
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.1.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.
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:

586

PTV AG

Chapter 7.5: PuT fare model

Illustration 191: Example for a distance-based fare with 5 fare stages

In Visum you model this fare as the following distance-based fare stages:
Number of fare points
5

Interpolate

Fare [CU]
No

10

10

No

16

20

Yes

24

30

No

24

> 30

---

[Empty field]

Fare stages for the example on distance-based fare

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.
By default, a zone-based ticket is only applicable for paths which only include stops, which
belong to fare zones of the ticket type's fare zone 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 traversed fare zones and thus the fare. More complex overlapping fare zones could
provide several possibilities of covering a path by fare zones. Visum then selects the minimum
number of overlapping 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".

PTV AG

587

Chapter 7: Operator model PuT

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"

Illustration 192: Example for a zone-based fare with three overlapping fare zones and six stops.

The fare zones in this example have different cardinalities - fare zone 2 is to be counted twice:
Fare zone

Cardinality
1

The following base fare is charged for the respective fare zones:

588

PTV AG

Chapter 7.5: PuT fare model

Number of fare zones

Base fare [CU]

2.00

3.00

3.50

>3

4.00

The result being, the traversed fare zones and thus also the fare for all the paths in the example
network:
Path

Traversed fare zone


numbers

Number of counted fare zones


(considering the cardinalities)

Base fare
[CU]

Stop 1 - Stop 2

2.00

Stop 1 - Stop 3

2.00

Stop 1 - Stop 6

1 and 3

3.00

Stop 1 - Stop 4

1 and 2

3.50

1 and 2

3.50

Stop 1 - Stop 5 directly via 2

Stop 1 - Stop 5 via 3 and 4

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.00

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 192, the following From-to zone-based fare can be modeled as
an alternative to the zone-based fare:

PTV AG

589

Chapter 7: Operator model PuT

to fare zone

2.00

3.50

(*) 3.00

3.50

3.00

3.50

3.00

3.50

2.00

from fare zone

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.

In Visum, the above matrix can be modeled as follows:


from FZ

to FZ

Fare [CU]

2.00

3.00

2.00

3.00

3.00

3.50

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:
from FZ

to FZ

Fare [CU]

All

2.70

All

[Empty field]

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 (shortdistance 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.

590

PTV AG

Chapter 7.5: PuT fare model

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:
max. run time

unlimited

max. distance

unlimited

max. number of stops

Fare

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.
max. run time

5 min

max. distance

unlimited

max. number of stops

Fare

0.30 CU

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 satisfied, 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 shortdistance 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.1.2

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.

PTV AG

591

Chapter 7: Operator model PuT

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 to all transport systems,
the most expensive minimum fare of all occurring transport systems, is the lower limit for the
total fare of the ticket type.
Below you will find a simple example on minimum fares (see "Example: Calculation of fixed
supplements" on page 592).

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


Transport system

Fixed supplement Minimum fare [CU]


[CU]

Rank Distance-based
supplement

IC

4.00

0.00

No

ICE

0.00

7.00

Yes

RE

0.00

0.00

No

These are the distance-dependent supplements for the ICE:

592

Number of fare points

Fare [CU]

50

0.50

100

1.00

PTV AG

Chapter 7.5: PuT fare model

Number of fare points

Fare [CU]

200

2.00

300

3.00

400

4.00

500

5.00

600

06:00

> 600

7.00

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:
1. Supplement once per transport system:
Path legs of the
connection

Fare points

IC

50

Base fare [CU]

Fixed
supplement
[CU]

Distance
supplement
[CU]

Minimum fare
[CU]

4.00

0.00

0.00

RE

200

0.00

0.00

0.00

IC

100

(*) 0.00

0.00

0.00

0.00

(**) 0.50

(***) 7.00

4.00

0.50

ICE

50

Sum

400

4.00

Total fare

8.50

(*) 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 594).
(***) 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:
Path legs of the
connection

Total fare

Fare points

Base fare [CU]

Fixed
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

Sum

400

0.00

0.50

4.00

(**) 7.00

(*) 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.50 CU is lower than the ICE minimum fare.
3. Supplement per path leg:

PTV AG

593

Chapter 7: Operator model PuT

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

(*) 4.00

0.00

0.00

ICE

50

0.00

0.50

(**) 7.00

Sum

400

8.00

0.50

4.00

Total fare

12.50

(*) Different than in the first case, reimposition of fixed IC supplement.


(**) 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:
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

Distance supplement for proportional calculation:


FP IC
FP ICE
---------------------------------- Supplement ICE ( FP ICE + TP IC ) + ---------------------------------- Supplement IC ( FP ICE + FP IC )
TPICE + FP IC
FPICE + FP IC

594

PTV AG

Chapter 7.5: PuT fare model

50 FP
100 FP
= ------------------ 5, 00 CU + ------------------ 3, 50 CU = 4, 50 CU
150 FP
150 FP
Distance supplement for additive calculation:
Supplement ICE ( FPICE ) + Supplement IC ( FP IC ) = 4, 00 CU + 2, 00 CU = 6, 00 CU

7.5.2

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 types and demand segments


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 included in the example: City, Metro and Long-distance rail. 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:

Fare system City


(Bus, Tram)
Fare system
Metro
Fare system Rail
long-distance

DSeg "Passengers without a monthly


pass"

DSeg "Passengers with a monthly pass"

Regular fare City (a Zone-based


fare),
Short-distance City (max. 10 min)

Monthly pass region

Normal fare metro


(a distance-based fare),
Short-distance Metro (max. 3 stops)

Monthly pass region

Single ticket rail

Monthly pass rail

Table 212: Linking fare systems and demand segments

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 600).

7.5.2.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

PTV AG

595

Chapter 7: Operator model PuT

system - even if path legs of other fare systems lie in between. All three cases are practicerelated.
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
fare systems City, therefore, the same ticket types are valid. The transport system Train
belongs to the fare system Rail.
To keep the example simple, let's assume the following ticket types:

Regular 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.
Regular 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. Due to the fare reference, the following fares apply for
the connection:
Fare refers to...
Path leg TSys

Fare system

Each path leg


separately

Each group of
contiguous path legs

1 Bus

City

60
(Short-distance)

100

2 Tram

City

100

All path legs together


100
also includes bus
at the end

3 Train

Rail

200

200

200

4 Bus

City

100

100

no extra fare

460

400

300

Fare sum

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:

596

PTV AG

Chapter 7.5: PuT fare model

Example: Fare reference and initial and transfer fares


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

Both fare systems therefore require an initial fare as a base value at trip start. Transfers within
the same fare system cost 50 CU as additional charge for "City", for "Rail" no extra costs are
charged. For a transfer from "Rail" to "City" an additional amount of 80 CU is charged, vice
versa however, there is a discount of 20 for a transfer from "City" to "Rail".
The table below displays the initial and transfer fares, which are added to the base fares listed
above:
Fare refers to...
Path leg TSys

Fare system

Each path leg


separately

1 Bus

City

100

Each group of
contiguous path legs
100

All path legs together


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 initial
and transfer
fares

210

160

80

Fare sum
(see above)

460

400

300

Total fare

670

560

380

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.2.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 let's look at the case of an individual fare system, which has three
different ticket types:
1. Fare condition descriptions:

PTV AG

597

Chapter 7: Operator model PuT

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

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.

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.

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
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 shortdistance 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.

598

PTV AG

Chapter 7.5: PuT fare model

7.5.2.3

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. Like the initial
fare, they are added to the ticket type's basic fare for the fare system.
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:
Initial and transfer fares (see ""Fare reference" of a fare system" on page 595)

7.5.2.4

Fare weights

For the fare computation it is assumed that passengers have full knowledge of all fare systems.
Thus, the minimum fare will be selected, if several fares applied to the connection taking the
fare system ranks into account. Fare weights can be used to model restrictions to the
assumption above. This is achieved by computing a 'perceived' fare for the alternatives on the
basis of the fare weight. The perceived fare will only be regarded for the selection of the real
fare.

Example:
Trip from C Town to A Town, part 3 (see "Procedure for ambiguous fare systems" on
page 600)

7.5.3

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 "Transport system-specific supplements" on page 591).
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 597).
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 596). 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 603).
The general case of several possible fare systems per path leg, however, requires an
extension of the previously described modeling.

PTV AG

599

Chapter 7: Operator model PuT

7.5.3.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:

Example: Fare calculation for ambiguous fare systems, trip to C Town, part 1
Let's consider the following path legs:
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

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:
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)

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.

600

PTV AG

Chapter 7.5: PuT fare model

Example: Fare calculation for ambiguous fare systems, trip to C Town, part 2
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 (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)

B Town

C Town

Intercity

Rail (#2)

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.
Note: The rank of a combination of fare systems T = {t1, t2,, tn} is defined as the maximum
rank of one of its fare systems: Rank(T) := maxiRank(ti).
With this specification one obtains an order on the set of all fare system combinations.
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.
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.

Example: Fare calculation for ambiguous fare systems, trip from C Town to A
Town bus terminal, part 3
As in the previous example, for the trip in the opposite direction the same combinations of the
same rank are returned from which the fare with the most favorable total fare is chosen. It is
assumed, that a combination costs 35 (Rail) plus 5 (City-City), i.e. 40 , whereas the other
variant costs 40 (Rail-Rail) plus 2 (City), i.e. 42 . On the basis of the previous assumptions
it follows, that the fare for Rail-City-City is chosen. This choice presumes the pedestrians' full
knowledge of all available fares. In reality, however, this is not always the case. Particularly it
can be assumed, that visitors and other groups do not have detailed knowledge of regional
fares like the City fare in our example, whereas the supra-regional Rail fare is well-known. To
model, for example, that a passenger uses a certain fare system (which is Rail in the example)
for a trip section which is as long as possible, the fare is weighted for the selection on the fare

PTV AG

601

Chapter 7: Operator model PuT

system level. This weight helps to determine a "perceived" fare, which is the basis for the
selected fare. In other words, fare weights of 1 for the fare system Rail and 10 for City will
change the choice, thus the fare Rail-Rail-City will be favorable (perceived fare is 40+20=60
compared to 85 for Rail-City-City).

Example: Fare calculation for ambiguous fare systems, trip to C Town, part 4
Let's now look at the variant, that the regional train itself goes to C Town:
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

C Town

Regional train

City (#1) or Rail (#2)

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:
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:

602

PTV AG

Chapter 7.5: PuT fare model

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.3.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.
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 weighted rank.
Compared to the fare, for the weighted fare, the fare weight for each fare system is
considered. 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:

PTV AG

603

Chapter 7: Operator model PuT

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.
If distance-based supplements have been activated for the ticket type, calculate and add
the distance-based supplement for the counted number of fare points. If the supplement
table does not contain an appropriate 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.4

Application of fares
With a fare model, fares can be taken into account in both the headway-based assignment and
the timetable-based assignment procedures. Alternatively, you can model a linear
dependence in terms of fare points measuring the traversed distance for the headway-based
assignment.
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 636).

604

PTV AG

Chapter 7.6: PuT operating indicators

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 532).

The indicators are described in the indicator categories. The following file lists the network
objects you can calculate indicators for: IndicatorAvailability.xls, in the directory ...Program
files\PTV Vision\PTV Visum 13\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. The
IndicatorSource.xls file, in the directory ...Program files\PTV Vision\PTV Visum 13\Doc\Eng of
your Visum installation, contains an overview of the indicators, the procedures used to
calculate them, and the calculation settings required. Basically, the following procedures are
relevant for the calculation:

PuT Operating Indicators


Territory indicators
PuT assignment
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:

7.6.1

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

Example for PuT operating indicators


The following example Example_LLE.ver (illustration 193) is used to illustrate the indicator
calculations. The description of the indicator categories pick up this example again. You can
find the example in the following directory: ...Users\Public\Public documents\PTV Vision\PTV
Visum 13\Example_Net\.

PTV AG

605

Chapter 7: Operator model PuT

Illustration 193: 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
a.m.

00:40

06:07
p.m.

00:45

19

daily

BUS <

40

10

27.5

06:02
a.m.

00:40

06:02
p.m.

00:45

19

daily

BUS >

30

40

7.5

05:37
a.m.

00:40

05:37
p.m.

00:13

19

weekdays

BUS <

40

30

7.5

06:29
a.m.

00:40

06:29
p.m.

00:13

19

weekdays

TRAIN >

20

40

10.0

06:29
a.m.

00:40

06:29
p.m.

00:16

19

daily

TRAIN <

40

20

10.0

06:09
a.m.

00:40

06:09
p.m.

00:16

19

daily

Table 213: Transport supply in Example_LLE.ver

606

PTV AG

Chapter 7.6: PuT operating indicators

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.42, page 645).
Valid day

Proj. factor transport supply

Proj. factor hourly costs

daily

365

365

weekdays

260

260

Table 214: Projection factors for the valid days in Example_LLE.ver

The projection factor for demand segment PuT is allocated as follows.


Demand segment

Projection factor

PuT

365

Table 215: Projection factor for the demand segment

Vehicles used
Vehicle type

Seat capacity

Total capacity

Standard bus

35

90

Low floor bus

35

50

Train

200

400

Table 216: Total capacity provided in the vehicles of example Example_LLE.ver

Fare model
The fare model includes two fare zones, which have been assigned the following stops.
Number

Name

FZ100

FZ200

10

A Village

20

C Village

30

B Village

40

X City

X
X

Table 217: Fare model in Example_LLE.ver

Stop 30 (B village) is located exactly between fare zones FZ100 and FZ200, and is therefore
assigned to both fare zones.

PTV AG

607

Chapter 7: Operator model PuT

Tickets and Fares


Fare zones

One-way ticket [CU] Four-trip ticket [CU]


One-way fare

Fare

Monthly pass [CU]

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 218: Fares of the fare model in Example_LLE.ver

Additionally, a supplement of 3.00 CU (currency units: for example, Euro, Pound, Dollar) is
required for each rail ticket.

Transport demand
The table 219 displays the number of passengers between the zones.
FromZone

ToZone

Line1

Line2

A Village

X City

Bus1

Train

Demand
2000

X City

A Village

Train

Bus1

2000

A Village

C Village

Bus1

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

200

2000
Sum

18400

Table 219: Transport demand between the zones in Example_LLE.ver

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
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

Cost rate per vehicle [CU/


Veh/AP]

7,000.00

7,000.00

20,000.00

Table 220: Cost rates for vehicles in Example_LLE.ver

608

PTV AG

Chapter 7.6: PuT operating indicators

7.6.2

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.

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.
Indicator

Description

Line network
length (directed)

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.

Line network
length
(undirected)

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.

Number of lines

The meaning of this indicator depends on the network object for which it is 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
Stop points take the number of lines into consideration, which traverse this stop
point. No line trip has to serve a 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.

Number of stop
points total

Number of stop points, which lie within a territory polygon.

Number of 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.

Table 221: Indicators for line route and timetable evaluation

PTV AG

609

Chapter 7: Operator model PuT

Indicator

Description

Stops served

The meaning of this indicator depends on the network object for which it is 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
Vehicle journeys take the number of stops into consideration, where a vehicle
journey 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 vehicle journey 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.

Start stop events Number of vehicle journeys, which start at a stop in the territory.
End stop events

Number of vehicle journeys, 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.

Table 221: Indicators for line route and timetable evaluation

610

PTV AG

Chapter 7.6: PuT operating indicators

Indicator

Description

Number of PuT
departures

The meaning of this indicator depends on the network object for which it is 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 vehicle journeys run by this line.
For line routes it returns the number of vehicle journeys run by this line route
For time profiles it returns the number of vehicle journeys using this time profile
For PuT operators it returns the number of vehicle journeys operated by this PuT
operator
For transport systems it returns the number of vehicle journeys operated with this
transport system
For stops it returns the number of vehicle journeys which stop for boarding. Stop
events at several stop points within the stop are counted repeatedly. If a stop is
traversed several times within a vehicle journey, the departures are also counted
repeatedly
For stop points it returns the number of vehicle journeys which stop for boarding.

Number of
In contrast to Number of PuT departures, the number of departures is returned by
departures-TSys transport system. Calculation is otherwise analog.
Number of PuT
arrivals

Number of vehicle journeys, which stop for alighting at the stop or the stop point.
Multiple stop events are counted several times for a stop.

Number of
arrivals-TSys

In contrast to Number of PuT arrivals, the number of arrivals is returned by transport


system. Calculation is otherwise analog.

Table 221: Indicators for line route and timetable evaluation

PTV AG

611

Chapter 7: Operator model PuT

Indicator

Description

Number of
service trips
uncoupled

The meaning of the indicator depends on the network object for which it is calculated:
For a vehicle journey it is the number, how often this vehicle journey has been
carried out in the particular time slot (AH, AP, TI)
For vehicle journey items it is returned, how often this vehicle journey traverses the
respective vehicle journey item (crucial are start and end stop points of the vehicle
journey). It is irrelevant whether boarding or alighting is permitted
For time profiles, the number of vehicle journeys is returned which use the time
profile in the particular time slot
For time profile items, the number of vehicle journeys is returned which traverse the
time profile item in the particular time slot (crucial are start stop point and end stop
point of the vehicle journey). It is irrelevant whether boarding or alighting is
permitted
For main lines/lines/line routes, the number of vehicle journeys in the time slot is
returned
For the line route course, the number of vehicle journey services 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 territory analyses, the number of vehicle journeys which are carried out in the
territory in the time slot is returned. A vehicle journey is added to the territory, if at
least one stop of the vehicle journey lies within the territory The stop point location
is not crucial, but the stop location.
For PuT operators, the number of vehicle journey services in the time slot of the
operator's vehicle journeys is returned
For line blocks, the number of occurrences of vehicle journeys in the line block is
returned
For links, the number of services in the time slot of vehicle journeys which traverse
a link is returned. A link is regarded as if being traversed, if the vehicle journey
traverses more than 50 % of the link's length
For a transport system, the number of vehicle journey services in the time slot of
vehicle journeys using this transport system is returned
For zones, a vehicle journey counts for a zone, if the zone is connected via a node
which is the access node to a stop area, and if the vehicle journey stops at one of
the stop points of the same stop for passenger boardings/alighting
For a stop the number of vehicle journeys is returned which stop at the stop for
passenger boarding/alighting in the particular time slot. Multiple stop events at stop
points of the stop are counted several times
For a stop point the number of vehicle journeys is returned which stop at the stop
point for passenger boarding/alighting in the particular time slot

Table 221: Indicators for line route and timetable evaluation

612

PTV AG

Chapter 7.6: PuT operating indicators

Indicator

Description

Number of
service trips

In contrast to the indicator Number of service trips uncoupled, coupled vehicle


journeys count as one vehicle journey for this indicator. If two vehicle journeys have
been coupled in a section, the vehicle journey item attribute has value 0.5 for each
service within the particular time slot, and 0.33 if three vehicle journeys have been
coupled, etc. Accordingly, coupled departures count as one departure in the stop point
attribute, for example.
Since a vehicle journey, a time profile and a line route can be coupled by section, this
indicator can only be returned for network objects with a unique location reference.
For line routes, time profiles and vehicle journeys, it cannot be returned.
For vehicle journey items it is returned, how often this vehicle journey traverses the
respective vehicle journey item (crucial are start and end stop points of the vehicle
journey). Coupled vehicle journeys count proportionally. It is irrelevant whether
boarding or alighting is permitted
For time profile items, the number of vehicle journeys is returned which traverse the
time profile item in the particular time slot (crucial are start stop point and end stop
point of the vehicle journey). Coupled vehicle journeys count proportionally. It is
irrelevant whether boarding or alighting is permitted.
For line route items, the number of vehicle journeys is returned which traverse the
line route item in the particular time slot (crucial are start stop point and end stop
point of the vehicle journey). Coupled vehicle journeys count proportionally. It is
irrelevant whether boarding or alighting is permitted.
For links, the number of services in the time slot of vehicle journeys which traverse
a link is returned. A link is regarded as if being traversed, if the vehicle journey
traverses more than 50 % of the link's length. Coupled vehicle journeys count
proportionally.
For zones, a vehicle journey counts for a zone, if the zone is connected via a node
which is the access node to a stop area, and if the vehicle journey stops at one of
the stop points of the same stop for passenger boardings/alighting. Coupled vehicle
journeys count proportionally.
For a stop the number of vehicle journeys is returned which stop at the stop for
passenger boarding/alighting in the particular time slot. Multiple stop events at stop
points of the stop are counted several times. Coupled vehicle journeys count
proportionally.
For a stop point the number of vehicle journeys is returned which stop at the stop
point for passenger boarding/alighting in the particular time slot. Coupled vehicle
journeys count proportionally.

Number of
service trips
(vehicle
combination)

For PuTDetail evaluations this indicator only differs from the Number of service trips
uncoupled, if there are vehicle journeys with several vehicle journey sections and
these differ in terms of the vehicle combination. In contrast to Number of service
trips uncoupled the number of service trips is distributed to the vehicle journey
sections in this case. If vehicle journey sections differ only in terms of the valid days,
the values Number of service trips (vehicle combination) and Number of service
trips uncoupled will match. Therefore, the evaluation of this indicator is useful for
territory analyses only for levels in combination with xVehComb.

Number of
service tripsTSys

In contrast to Number of service trips, the number of vehicle journeys is returned by


transport system. Calculation is otherwise analog. Especially coupled vehicle
journeys only count proportionally.

Table 221: Indicators for line route and timetable evaluation

PTV AG

613

Chapter 7: Operator model PuT

Indicator

Description

Mean service trip Calculation is dependent on the network object.


length
For a transport system, service km / number of service trips applies
Otherwise, service km / number of departures applies
Mean service
time

Calculation is dependent on the network object.


For a transport system, service time / number of service trips applies
Otherwise, service time / number of departures applies

Is coupled

(Respective) time profile is coupled with another time profile (1) or not coupled (0).

Effectively
coupled

An effective coupling means the following: a vehicle journey, which is coupled with
another vehicle journey via its corresponding time profile, is really carried out (in other
words: at least one vehicle journey service is required for each of the coupled time
profiles, these vehicle journeys have to be active and require a valid 'valid day'. For a
valid valid day, the valid day is within the analysis period and both coupled vehicle
journeys are carried out on the same day).

Table 221: Indicators for line route and timetable evaluation

Calculation example: Number of departures per transport system

Number of departures for analysis period = number of vehicle journeys, 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 vehicle journeys, 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 vehicle journeys 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 analysis time interval TI1 = number of vehicle journeys between
08:00 AM and 09:00 AM.
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)

614

PTV AG

Chapter 7.6: PuT operating indicators

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.
Indicator

Description

Service kilometers Kilometers traversed by vehicle journeys. Trip length via all vehicle journeys 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).

Service time

Time required by vehicle journeys. Trip length via all vehicle journeys and number of
departures.

Section service
time

Compared to service time, the duration of each individual vehicle journey section is
added (as long as it lies within the analysis period). Also the dwell time between
adjacent vehicle journey sections is included.

Empty kilometers

Kilometers traversed by empty trips. Compared to vehicle journeys, 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


added (as long as it lies within the analysis period).

Empty time

Time required by empty trips. Compared to vehicle journeys, 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 EmptyKm, the length of each individual vehicle journey section is


added (as long as it lies within the analysis period).

Out-of-depot time

Operating time = Service time + Empty time

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).

Stop time

Stop time of all stop events

Section stop time

In contrast to a stop time, the stop times of overlapping vehicle journey sections are
counted multiple times.

Seat capacity

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.

Table 222: Indicators of the transport supply

PTV AG

615

Chapter 7: Operator model PuT

Indicator

Description

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 vehicle journey 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.

Length

Length covered by the time profile items in the territory (attribute is only available via
Territory - PuT Detail, for level Territory x Time profile (x Vehicle combination) and
Territory X Vehicle journey (x Vehicle combination)).

Run time

Travel time used to cover the time profile items in the territory, (attribute is only
available via Territory - PuT Detail, for 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
As above, but the addition to the reference object is instead carried out with the
vehicles (in
share of vehicle journey sections of the reference object in the service time of all
proportion to time) vehicle journey sections.

Table 222: Indicators of the transport supply

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

616

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

PTV AG

Chapter 7.6: PuT operating indicators

For the bus it applies that ServiceKm (TI1) = 113.75 km. The calculation is made clearer by
illustration 194.

Illustration 194: 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 194).
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

PTV AG

617

Chapter 7: Operator model PuT

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 194).
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: ...Program files\PTV Vision\PTV Visum 13\Doc\Eng).
Indicator

Description

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 223: Indicators of the network performance

618

PTV AG

Chapter 7.6: PuT operating indicators

Indicator

Description

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
destination zone. This attribute is only available for the elements of the line
hierarchy.

PTrips Unlinked
with 2xTrans
(DSeg)

Passenger trips with exactly two transfers on their way from origin zone to
destination zone. This attribute is only available for the elements of the line
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.


Boarding passengers = Origin boardings + Direct transfers + Transfers Walk-Board
(This attribute is only available for the line hierarchy, for stops and stop points.)

Alighting
passengers (DSeg)

Number of alighting passengers.


Alighting passengers = Destination alightings + Direct transfers + Passengers
transferring alight-walk
(This attribute is only available for the line hierarchy, 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.)

Table 223: Indicators of the network performance

PTV AG

619

Chapter 7: Operator model PuT

Indicator

Description

PassThrough

Number of through-going passengers. These are all passengers traveling with a


line, which traverses this item of a line route / time profile / vehicle journey,
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
Number of through passengers without stop event. These are all passengers
without stop (DSeg) 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


Passenger Transfers = Direct transfers + Passengers transferring walk-board +
Passengers transferring alight-walk
(This attribute is only available for stops and stop points.)

PassTransAlightWalk (DSeg)

Number of passengers alighting at this stop or stop point and walking to another
stop or stop point for transfer
(This attribute is only available for stops and stop points.)

PassTransDir
(DSeg)

Number of passengers transferring to another line at this stop or stop point.


(This attribute is only available for stops and stop points.)

PassTransWalkBoard (DSeg)

Number of passengers boarding at this stop or stop point after walking from
another stop or stop point.
(This attribute is only available for stops and stop points.)

Table 223: Indicators of the network performance

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

620

PTV AG

Chapter 7.6: PuT operating indicators

For the train it applies that 12000 10 km(C<->X) = 120000


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.11.3, page 242).

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 195:

Illustration 195: 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

PTV AG

621

Chapter 7: Operator model PuT

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 196.

Illustration 196: 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)


The illustration 197 gives an overview of the cost and revenue model in Visum and the
interrelations 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 1220).

622

PTV AG

Chapter 7.6: PuT operating indicators

Illustration 197: Calculation schema for costs and revenues

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 OD trips total indicates the number of
passenger trips in the assignment time interval; it thus varies according to the particular
assignment time interval. Thus, the revenues also vary according to the temporal position
and length of the assignment time interval. Cost calculation, however, refers to the analysis
period. As the assignment time interval often only consists of the peak hour (e.g. evening
rush hour from 4-6 p.m.), project the results to the analysis period when you want to calculate
cost coverage in your model or combine indicators calculated in the assignment with
indicators calculated in the procedure PuT operating indicators (file IndicatorSource.xls, in
the directory ...Program files\PTV Vision\PTV Visum 13\Doc\Eng). To create identical
reference periods, you have to define a projection factor from the assignment time interval to
the analysis period by demand segment (see User Manual, Chpt. 7.2, page 1215). The
projection factor 1 is only correct here, if you carry out an assignment for the whole day.

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:

PTV AG

623

Chapter 7: Operator model PuT

Vehicle type-dependent costs


Hourly costs / Cost
time

Time-dependent costs for personnel


Time costs = service time hourly costs rate of vehicle journeys + 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 vehicle journeys + empty kilometers
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 224: 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 cost" on page 628).

Link costs / Cost


links

Costs for the usage of links (infrastructure cost) The link costs are divided equally
between the vehicle journeys 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 626).

Operator costs /
Cost 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 cost" on page 629).

Table 225: Infrastructure costs

The total costs which accumulate for operating public transport, are returned in the following
attribute.
Total cost
Cost

Costs = time costs + distance costs + vehicle costs + stop point costs + link costs + operator
costs

Table 226: Total cost

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 1216). 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).

624

PTV AG

Chapter 7.6: PuT operating indicators

Hourly costs (attribute Cost time)


Time costs = service time hourly costs rate of vehicle journeys + 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 vehicle journeys + empty kilometers kilometer cost
rate of empty trips
Service kilometers for transporting passengers are calculated directly from the vehicle
journeys in the timetable.
Empty kilometers arise from empty 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.28.2, page 441), 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


This example regards the following vehicle type-specific cost rates (see "Example for PuT
operating indicators" on page 605).
Vehicle units

Standard bus

Low floor bus

Train

Service

Service

Service

Empty

Empty

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

Cost rate per vehicle unit [CU/


Veh]

7,000.00

7,000.00

20,000.00

Reference period of the cost


rate per vehicle unit

Analysis period

Analysis period

Analysis period

Table 227: Cost rates for the vehicle units

PTV AG

625

Chapter 7: Operator model PuT

Vehicle combinations

Standard bus
Service

Low floor bus

Empty

Service

Train

Empty

Service

Empty

Cost rate per hour [CU/h]

0.00

0.00

0.00

0.00

50.00

50.00

Cost rate per km [CU/km]

0.00

0.00

0.00

0.00

0.00

0.00

Table 228: Cost rates for the vehicle combinations

The following distances and times accumulate for the train:


Vehicle combination
Train

ServiceKm

EmptyKm

380 km

0 km

Service time

Empty time

10.13 h

0h

Table 229: Distances and times for the vehicle combination Train in the analysis period

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)
CU
CU
= 10 -------- 380 km + 10 -------- 0 km = 3800 CU
km
km
Time costs / analysis period
CostTime(AP) = CostTimeService ServiceTime(AP) + CostTimeEmpty EmptyTime(AP)
CU
CU
= 750 -------- 10.13 h + 500 -------- 0 h = 7600 CU
h
h
Vehicle costs / analysis period
CostVehicle(AP) = Cost rate vehicle unit Number of vehicles
CU
= 20000 ---------- 1 Veh = 20000 CU
Veh

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 vehicle journeys which use the link. Up to three cost values
(attributes CostRate1_PuTSys - CostRate3_PuTSys) can be specified per link and transport
system to model link costs (see User Manual, Chpt. 2.14.7, page 283). 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 vehicle
journeys is then carried out according to the formulas described below.

626

PTV AG

Chapter 7.6: PuT operating indicators

Cost type depreciation costs


CostValue: for example investment costs for a link (link attributes CostRate1-PuTSys, also 2 and-3)
DT

CostValue L, T q ( q 1 )
1 - ---------------with q = 1 + p/100
CostsLinkAP, L, T = ---------------------------------------------------------------------DT
FacTS
q 1
CostsLink AP, L, T
CostsLinkV, L, T = -----------------------------------------V
L, T
Cost type running costs
CostValue: for example annual maintenance costs for a link (link attributes CostRate1-PuTSys, also 2
and-3)

CostValue L, T
CostsLinkV, L, T = -------------------------------------- VL, T FacTS
Cost type utilization costs
CostValue: for example fees for using a link (link attributes CostRate1-PuTSys, also 2 and-3)
CostsLinkV, L, T = CostValueL, T
CostValueL, 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 vehicle journeys or allocated only
to vehicle journeys which end or start at this stop point (see User
Manual, Chpt. 7.3.2.5, page 1225).

CostsLinkAP, L, T

Link costs of the link in the analysis period (AP)

CostsLinkV, L, T

Costs for a vehicle journey V which uses the link

VL, T

Number of vehicle journeys of transport system T which use link L.

FacTS

The transport supply projection factor from AP to AH (see User


Manual, Chpt. 2.42.3, page 647)

DT

Depreciation time in years

Interest rate [%]

Table 230: Formulas for calculating link costs

Calculation example: Link costs for vehicle journeys in the analysis period

Example for depreciation 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 vehicle journeys of the transport


system train

19

Table 231: Example calculation for link depreciation costs

PTV AG

627

Chapter 7: Operator model PuT

Link Cost 2 of link 4


CostsLinkAP, L, T

100000 1.07

Link Cost 2 of vehicle journey 58

39.008 19 = 2.053

10

1
1
- ---------- = 39.008
0.07 -------------------------10
365
1.07 1

Table 231: Example calculation for link depreciation costs

Example for running costs

Cost rate 3 PuTSys(Bus)

100 CU

Links traversed by vehicle journey 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

Projection factor transport supply (FacTS)

365

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 vehicle journey 96

0.01154 + 0.00288 = 0.01442 CU

Table 232: Example calculation for running costs of links

Example for utilization costs (in the example, stored in attribute Link Cost 1)

Cost rate 1 PuTSys(Train)

100 CU

Length of link 4

10 km

Length reference of cost rate 1

km

Link Cost 1 for vehicle journey (in this example, it is 100 CU/km 10km = 1000 CU
constant for all vehicle journeys of the train)

Table 233: Example calculation for link utilization costs

7.6.6.3

Stop point cost

Stop point costs are infrastructure costs which accumulate when using a stop point. The costs
are defined for each stop point. The costs are evenly distributed between the vehicle journeys
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.26.2, page 425). 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 vehicle
journeys is then carried out according to the formulas described below.

628

PTV AG

Chapter 7.6: PuT operating indicators

Cost type depreciation costs


CostValue: for example investment costs for a stop point (Stop point attributes CostRate1 to 3)
DT

CostValue SP q ( q 1 )
1 - ---------------with q = 1 + p/100
CostsSP AP, SP = -------------------------------------------------------------------AD
FacTS
q 1
CostsSP AP, SP
CostsSP V, SP = ----------------------------------V
SP
Cost type running costs
CostValue: for example annual maintenance costs for a stop point (Stop point attributes CostRate1 to 3)

CostValue SP
CostsSP V, SP = ------------------------------------V

FacTS
SP

Cost type utilization costs


CostValue: for example fees for using a stop point (Stop point attributes CostRate1 to 3)
CostSPV, SP = CostValueSP
CostValueSP

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 vehicle journeys or allocated only to vehicle
journeys which end or start at this stop point.

CostsSPAP, SP

Stop point costs of the stop point SP in the analysis period (AP).

CostsSPV, SP

Costs for a vehicle journey V which uses the stop point SP.

VSP

Number of vehicle journeys which use stop point SP.

FacTS

The transport supply projection factor from AP to AH (see User Manual, Chpt.
2.42, page 645)

DT

Depreciation time in years

Interest rate [%]

Table 234: Formulas for the calculation of stop point costs

7.6.6.4

Operator cost

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 vehicle journeys, which are operated by this operator, a
distribution key can be specified which consists of the following weighted indicators

PTV AG

Service kilometers (WeightServKm)


Seat kilometers (WeightSeatKm)
Service time (WeightServTime)
Number of vehicle journeys (WeightJourneys)
629

Chapter 7: Operator model PuT

Passenger trips unlinked (WeightPTripsUnlinked)


Passenger kilometers (WeightPassKmTrav)

With the values of any combination of these six attributes, you can thus distribute the operator
costs onto vehicle journeys. The weighting factors must amount to 100 % (see User Manual,
Chpt. 7.3.2.5, page 1225).
Distribution of operator costs O on a vehicle journey
The share of one vehicle journey V in the operator costs of its operator O is:

SeatKm V
ServKm V
Share V = ----------------------------------------------- WeightServKm + ------------------------------------------------ WeightSeatKm
SeatKm V
ServKm V

V FO

V FO

ServTime V
1
+ ---------------------------------------------------- WeightServTime + -------------------------------------------------------- WeightJourneys
NumberVehJourneys
ServTimeV

V FO

PassKmTrav V
+ ------------------------------------------------------------- WeightPassKmTrav
PassKmTrav V

V FO

PTripsUnlinked V
+ -------------------------------------------------------------------- WeightPTripsUnlinked
PTripsUnlinked V

V FO

Cost type depreciation costs

CostValueO: for example investment costs for a depot


DT

CostValue O q ( q 1 )
1
- ----------------- with q = 1 + p/100
CostOpAP, O = -----------------------------------------------------------------DT
FacTS
q 1
CostOpV = CostOp AP, O Share V
Cost type running costs

CostValueO: = for example annual maintenance costs for the depot

CostValue O Share V
CostOpV = -----------------------------------------------------FacTS
ShareV

The share of one vehicle journey V in operator (O) costs

FO

Number of all vehicle journeys of operator O

CostValueO

Cost value which is specified as operator attribute

CostOpAP, O

Operator costs of operator O in analysis period (AP)

CostOpV

Operator costs for one vehicle journey V by operator O.

FacTS

The transport supply projection factor from AP to AH

DT

Depreciation time in years

Interest rate [%]

Table 235: Formulas for calculating operator costs

630

PTV AG

Chapter 7.6: PuT operating indicators

Calculation example: Depreciation costs


Cost rate 1: Investment costs for depot

7500000 CU

Depreciation time DT

10 years

Interest rate

7%

Projection factor transport supply (FacTS)

365

Operator Cost 1 for "Urban operator"

7500000 1.07 0.07- --------1-----------------------------------------------------------


= 2925.57 CU
10
365
1.07 1

10

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"

46,550 km

Weight passenger kilometers

50 %

Passenger kilometers of trip 96

2,495.0 km

Passenger kilometers total for operator


"Urban operator"

109,000 km

Share of vehicle journey 96 in operating costs

962.5
2495
27.5----------- 0.25 + ---------------- 0.25 + -------------------- 0.5 = 0.022
46550
109000
1330

Operator Cost 1 for vehicle journey 96

2925.57 CU 0.022 = 63.73 CU

Table 236: Calculation example for depreciation costs of the operator

Calculation example: Running costs


Cost rate 2: Maintenance cost for depot

80,000 CU

Time reference of the cost rate

Analysis horizon

Projection factor transport supply (FacTS)

365

Operator Cost 2 for "Urban operator"

80000
---------------- = 219.18
365

Weight service kilometers

25 %

Service kilometers of trip 96

27.5 km

Service kilometers total for operator "Urban


operator"

1,330 km

Weight seat kilometers

25 %

Seat kilometers of trip 96

962.5 km

Table 237: Calculation example for the running costs of the operator

PTV AG

631

Chapter 7: Operator model PuT

Seat kilometers total for operator "Urban


operator"

46,550 km

Weight passenger kilometers

50 %

Passenger kilometers of trip 96

2,495.0 km

Passenger kilometers total for operator "Urban


operator"

109,000 km

Share of vehicle journey 96 in operating costs

27 . 5
962 . 5
2495 . 0
------------- 0, 25 + ---------------- 0, 25 + -------------------- 0 . 50 = 0 . 022
1330
46550
109000

Operator Cost 2 for vehicle journey 96

80000 0 . 022
------------------------------------- = 4.5 CU
365

Table 237: Calculation example for the running costs of the operator

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 by number of fare points, weighting by
number of path legs).
Specification of a revenue for each fare point
The revenue results from the following calculation: revenue/fare point multiplied by the
number of fare points. The revenue distribution can also be modified by specific parameter
settings (fixed amount per path leg, weighting by number of fare points, 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 by number of
fare points, weighting by number of path legs, and transport system-specific distribution of
supplements).

The decision for one of these three possibilities depends on the model's 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 below. 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.
Indicator

Description

Total revenue

Total revenue from fare revenues which apply to the network object.

Revenue-DSeg

Revenue by demand segment from fare revenues which apply to the network
object.

Table 238: Revenue indicators

632

PTV AG

Chapter 7.6: PuT operating indicators

Indicator

Description

Revenue total
Total revenue from fare gains which applies to the territory and the selected level.
(length-proportional) Distribution is proportional to the link lengths of the traversed links.
Revenue-DSeg
Like revenue total (length-proportional), but only the revenue by demand
(length-proportional) segment.
Revenue total (fare
point-proportional)

Total revenue from fare gains which applies to the territory and the selected level.
Distribution is proportional to the number of traversed fare points on links and time
profile items.

Revenue-DSeg (fare Like revenue total (fare point-proportional), but only the revenue by demand
point-proportional)
segment.
Revenue
PTripUnlinked

Revenue per passenger trip = Revenue total / PTripsUnlinked

Revenue PTripsUnlinked_DSeg

Revenue per demand segment / passenger trips unlinked per demand segment

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 unlinked

Table 238: Revenue indicators

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 636). The following route table (PuT path legs) provides an
overview of all other indicators required, including the passenger trips.
From zone

To zone

Line

FromSPoint

ToSPoint Passenger
trips

A Village
(100)

X City
(200)

BUS1

10

20

Train

20

40

1,501

Fixed revenue Revenue share


per passenger (Weighted with
trip [CU]
number of path
legs)
4.00

1501 4
--------------------2

4.00

1501 4
--------------------2

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

Table 239: Revenue share per path leg

PTV AG

633

Chapter 7: Operator model PuT

X City (200) A Village


(100)

BUS1

40

10

1,000

4.00 1000 4.00

X City (200) A Village


(100)

Train

40

20

1,000

4.00

1000 4
--------------------2

BUS1

20

10

4.00

1000 4
--------------------2

X City (200) C Village


(201)

Train

40

20

5,000

4.00 5,000 4.00

X City (200) B Village


(202)

BUS1

40

30

2,000

4.00 2,000 4.00

C Village
(201)

A Village
(100)

BUS1

20

10

200

C Village
(201)

X City
(200)

Train

20

40

5,000

4.00 5,000 4.00

B Village
(202)

X City
(200)

BUS1

30

40

2,000

4.00 2,000 4.00

4.00 200 4.00

Table 239: Revenue share per path leg

Revenues per line then result from summation of the revenue shares for each line.
Line

Revenue per line

Bus1

3002 + 1996 + 800 + 4000 + 2000 + 8000 + 800 + 8000 = 28598

Train

3,002 + 2,000 + 20,000 + 20,000 = 45,002

Table 240: Revenue per line

7.6.7.2

Revenue calculation from fixed revenue per traversed fare


point

If fare points have been defined for links or time profile items of the model, revenue calculation
can regard a fixed revenue per traversed fare point (see User Manual, Chpt. 7.5, page 1230).
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.
From To
zone zone

Line

100

BUS1

100

200

200

From
SP

To SP

NumFP

10

20

10

Train

20

40

20

BUS1

10

40

29

PTrips

1501

Fixed
revenue per
FP [CU]

Revenue share (Weighted


with number of path legs)

0.20 1501 ( 20 + 10 ) 0 . 2
-------------------------------------------------------2
0.20 1501 ( 20 + 10 ) 0 . 2
-------------------------------------------------------2

499

0.20 499 29 0 . 2

Table 241: Revenue share per path leg

634

PTV AG

Chapter 7.6: PuT operating indicators

100

201

BUS1

10

20

10

200

0.20 200 10 0 . 2

200

100

BUS1

40

10

30

1,000

0.20 1000 30 0 . 2

200

100

Train

40

20

20

1,000

0.20 1000 ( 20 + 10 ) 0 . 2
-------------------------------------------------------2

BUS1

20

10

10

0.20 1000 ( 20 + 10 ) 0 . 2
-------------------------------------------------------2

200

201

Train

40

20

20

5,000

0.20 5000 20 0 . 2

200

202

BUS1

40

30

10

2,000

0.20 2000 10 0 . 2

201

100

BUS1

20

10

10

200

201

200

Train

20

40

20

5,000

0.20 5000 20 0 . 2

202

200

BUS1

30

40

10

2,000

0.20 2000 10 0 . 2

0.20 200 10 0 . 2

Table 241: Revenue share per path leg

Revenues per line then result from summation of the revenue shares for each PuT path leg.
Line

Revenue per line

Bus1

4,503 + 2,894 + 400 + 6,000 + 3,000 + 4,000 + 400 + 4,000 = 25,197

Train

4,503 + 3,000 + 20,000 + 20,000 = 47,503

Table 242: Revenue per line

Fare points can be defined for links and also for time profile items. In the calculation of the
revenue share for each path leg, the sum of fare points at both of those network objects goes
in.
TW1

TW2

T W3

Path legs

Stop points

H1

H2

TP at time profiles (NumT Ps)

10

TP at links (NumTPs-TSys)

TP at path legs (NumTPs)

12

H3

H4

10

H5

10

21

13

Illustration 198: Calculation of the fare points for path legs

PTV AG

635

Chapter 7: Operator model PuT

7.6.7.3

Revenue calculation using the fare model

The most precise variant of the revenue calculation is the one which is based 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 582). A fare model provides a specific fare for
each PuT path.

Revenue =
Volume Fare
[CU]

Fare = Base
fare +
Supplement
[CU]

Supplement
for Train [CU]

One-way
ticket base
fare [CU]

Number of
fare zones

Passenger
trips

Path legs

To zone

From zone

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 636). With a zone-based fare, the following revenues result for
the paths in the example Example_LLE.ver.

A Village X City

Bus1
Train

1,000

3.00

3.00

6.00

6,000.00

A Village X City

Bus1

1,000

3.00

0.00

3.00

3,000.00

A Village C Village Bus1

200

2.00

0.00

1.00

200.00

X City

A Village Bus1

1,000

3.00

0.00

3.00

3,000.00

X City

A Village Bus1
Train

1,000

3.00

3.00

6.00

6,000.00

X City

C Village Train

5,000

1.00

3.00

4.00

20,000.00

X City

B Village Bus1

2,000

1.00

0.00

1.00

2,000.00

200

1.00

0.00

1.00

200.00

C Village X City

C Village A Village Bus1


Train

5,000

1.00

3.00

4.00

20,000.00

B Village X City

Bus1

2,000

1.00

0.00

1.00

Total

2,000.00
62,400.00

Table 243: Calculation of the revenues per path (PuT routes)

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.

636

With Weight number of path legsyou 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 Weight number of fare points the distribution will be based on the ratio between the
number of fare points on the path leg and the number of fare points on the total path. Thus
you can achieve, that longer (in terms of the number of fare points) path legs receive a
greater portion of the revenues.
You can select any weighting between both distribution possibilities, number of path legs
and number of fare points.

PTV AG

Chapter 7.6: PuT operating indicators

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.

Note: Revenue distribution does not regard how the revenue was calculated (fare model,
fixed revenue per passenger trip or fixed revenue per fare point).
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
NumPL
NumFarePt-PL
NumFarePt-Total
RevShare-PathLeg
W-NumFarePt
W-NumPL
Rev-PassTrip
Rev-Fix
Rev-PathLeg

Number of path legs in a passenger trip


Number of fare points in a path leg
Total number of fare points in the passenger trip
Share of the path revenue, which applies to the path leg
Weighting of fare points (length)
Weighting of path legs

W-NumFarePt + W-NumPL=1.0

Revenue per passenger trip


Revenue which is distributed to each path leg as a fixed amount
Revenue which is distributed to the path leg

The revenue distribution is also demonstrated with the example Example_LLE.ver. A zonebased 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 636).
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.
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)

5 FP + 5 FP
------------------------------- = 0 . 5
20 FP

Number of path legs of Path 1

Table 244: Revenue calculation for the path leg Bus1

PTV AG

637

Chapter 7: Operator model PuT

Share-PathLeg(Bus1)

1
--2

Revenue on Path 1

6000 CU

Weighting of fare points

75 %

Weighting of path legs

25 %

Revenue Path Leg(Bus1)

FP + 5 FP
1
5
------------------------------- 0. 75 + --- 0. 25 6000 CU = 3000 CU
20 FP

Table 244: Revenue calculation for the path leg Bus1

If you want to return the revenues on the line level, the following calculation thus applies.
Line

FromZone

ToZone

PTripsUnlinked

Fare

Revenue = PTrips Fare

BUS1

A Village

X City

1,000

3.00

3,000.00

A Village

X City

1,000

6.00

1
6000 --- = 3000
2

A Village

C Village

200

1.00

200.00

B Village

X City

2,000

1.00

2,000.00

C Village

A Village

200

1.00

200.0

X City

A Village

1,000

3.00

3,000.00

X City

A Village

1,000

6.00

1
6000 --- = 3000
2

X City

B Village

2,000

1.00

2,000.00

X City

C Village

5,000

4.00

20,000.00

X City

A Village

1,000

6.00

1
6000 --- = 3000
2

C Village

X City

5,000

4.00

2,000.00

A Village

X City

1,000

6.00

1
6000 --- = 3000
2

Total
TRAIN

=16,400.00

Total

=46,000.00

Table 245: Aggregation of the path leg revenues to lines

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.
S1

Bus 1
2 FP

S2

Train
6 FP

S3

Bus 2

S4

4 FP

Illustration 199: Example network for fixed amount per path leg

638

PTV AG

Chapter 7.6: PuT operating indicators

Passenger trips

Total number of fare points

12

Share-FarePt(Bus1)

2
------ = 0 . 167
12

Share-FarePt(Train)

6
------ = 0 . 5
12

Share-FarePt(Bus2)

4
------ = 0 . 333
12

Number of path legs

Share-PL

1
--- = 0 . 333
3

Rev-PassTrip

3.00

Table 246: Input data for the calculation example


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 247: Revenue distribution W-NumFP = 1.0, W-NumPL= 0.0, FixSuppl = 0


Path leg

Share per path leg

Revenue per path leg

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 248: Revenue distribution W-NumFP = 0.5, W-NumPL = 0.5, FixSuppl = 0.00
Path leg

Share per path leg

Revenue per path leg

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 249: Revenue distribution W-NumFP = 0.5, W-NumPL = 0.5, FixSuppl = 0.20

When using a fare model (see "Revenue calculation using the fare model" on page 636), the
distribution of supplements can also be influenced. With the option Distribute supplements
to transport systems you have the following possibilities:

PTV AG

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.

639

Chapter 7: Operator model PuT

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.

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.
TSys
(#Rank)

Number of
fare points on
path leg

Distribution of
the base fare
[CU]

Fixed
supplement
[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

IC (#2)

100.00

10.00

7.00

(**) 3.50

2.33

RE (#3)

100.00

10.00

0.00

0.00

2.33

30.00

(*) 7.00

7.00

7.00

Sum

2.33

(*) 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.
Indicator

Description

CostCov total

Expresses the cost coverage in absolute numbers.


CostCov total = Revenue total (length proportional) - Costs

CostCov Percent [%]

Expresses the cost coverage in percent.


Revenue tot (length prop)
CostCov [%] = -------------------------------------------------------------------- 100
Cost

Cost coverage per


passenger trip unlinked

Expresses the cost coverage per passenger trip.


CostCov Tot
CostCov PTripUnlinkef = ---------------------------------------PTripsUnlinked
This attribute is only available for the elements of the line hierarchy and
for PuT operators and transport systems.

Table 250: Indicators for the cost coverage calculation

For the application example, cost coverage data on line level is calculated as follows for Bus1
for example.

640

PTV AG

Chapter 7.6: PuT operating indicators

Total revenue

16400.00 CU

Cost

36321.86 CU

CostCov total

16400.00 CU - 36321.86 CU = -19921.86 CU

CostCov Percent [%]

36321.86
---------------------------- 100 = 45.15 %
16400.00

Passenger trips unlinked

8,400

Cost coverage per passenger trip


unlinked

-19921.86
------------------------------ = -2.37 CU
8400

Table 251: Cost coverage calculation from revenues and costs

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 to 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 252).
Indicator category

Projection factor
Transport supply /
Valid day

General indicators

Transport supply

Projection factor
Hourly costs / Valid
day

Network performance
Costs (apart from Cost Time)
Cost Time

Projection factor by
DSeg

X
X
X

Revenues

Table 252: Which projection factor applies for the calculation of indicators?

PTV AG

641

Chapter 7: Operator model PuT

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.
Valid day

weekdays (Monday to Friday)

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 253: Difference in the projection to AH for ServiceKm and PassengerKm

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

642

PTV AG

Chapter 7.6: PuT operating indicators

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
indicate correct weekly values as PuT volumes per analysis period, the following projection
factors are applied to the "commuters" demand segment.
Projection from ... to ...

Factor

Assignment time interval AP

Assignment time interval AH (= year)

5 52 = 260

The following example of a vehicle journey with two sections (illustration 200) 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 200 and table 254, vehicle journey section 1 is served daily, whereas
vehicle journey section 2 is available only on Sundays and public holidays.
8:00

7:00

6:00

0 km
1

10 km
20 km
2

30 km

s
Illustration 200: Time-distance diagram for a vehicle journey with two vehicle journey sections
VehJourney
Valid day

VehJournSect 1

VehJournSect 2

Daily

Sunday+Holiday

Projection factor Analysis Horizon


Departure

06:30 a.m.

Arrival

07:30 a.m.

Trip length

30 km

52

63

30 km

20 km

Trip length 6:30 - 7:00

10 km

10 km

0 km

Trip length 7:00 - 7:15

10 km

10 km

10 km

Trip length 7:15 - 7:30

10 km

0 km

10 km

200

100

Seat capacity

Table 254: Further specifications for the vehicle journey with two VJ sections

PTV AG

643

Chapter 7: Operator model PuT

The table 255 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.
Analysis period Mon-Sun
VehJournSect 1

200 seats 20 km 7 days = 28000 km

VehJournSect 2

100 seats 20 km 1 day = 2000 km

Sum

30000 km

Analysis horizon
VehJournSect 1

28000 km 52 = 1456000 km

VehJournSect 2

2000 km 63 = 126000 km

Sum

1582000 km

Analysis time interval Tue 7:00 8:00


VehJournSect 1

200 seats 10 km = 2000 km

VehJournSect 2

100 seats 0 km =

Sum

0 km
2000 km

Table 255: Calculation of seat kilometers

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 256, this is the case on
Sunday. The calculation of the service time is carried out in the same way.
Analysis period MonSun

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

10 km 1
+ 10 km 1
+ 10 km 1

10 km 52
+ 10 km MAX(52;63)
+ 10 km 63

20 km 0

150 km

8,020 km

10 km

Sunday

Sum

Table 256: Calculation of service kilometers

644

PTV AG

Chapter 7.6: PuT operating indicators

7.6.8.3

Aggregation along the line hierarchy

Based on the value calculated by vehicle journey section, Visum internally sums up all
indicators along the line hierarchy. Here, internally means that the user cannot view all
indicators on the vehicle journey section level. This is due to the memory which is required for
the data storage). This also applies to indicators are evaluated by territory or time slice.

Illustration 201: 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 202: Aggregation of the service kilometers from the trips onto the line

PTV AG

645

Chapter 7: Operator model PuT

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 949) or during the calculation of the indicators for
the analysis period. In the last case, the complete days of the analysis period are treated
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 645). 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 646). A calculation example
can also be found in a different place (see "Measurement of the transport supply" on
page 615).
3

Links with run times

Line route

Time profile

Line route with


interpolated run times

Stop point exactly


between B and C

C
2

10

4 * 3 / (3 + 6*0.5)
2
A

2
B

2
X

2
C

8
D

Illustration 203: 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.

646

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.

PTV AG

Chapter 7.6: PuT operating 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.

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 204, 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.
Link 1: 10km
Trip

H1

H2

20%

H3

ServiceKm Link 1: 0km

H3

ServiceKm Link 1: 8km

80%
Trip

H2

H1

80%

20%
Illustration 204: Partially traversed links

7.6.8.7

Impact caused by couplings

For some indicators, coupled vehicle journeys are counted proportionally. This means, that two
vehicle journeys 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 vehicle journeys 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.

PTV AG

647

Chapter 7: Operator model PuT

19km

2km

Trip 1

ServiceKm Trip 1: (19km / 2) + 2km = 11.5km


Section-ServiceKm Trip 1: 19km + 2km = 21km

Trip 2

ServiceKm Trip 2: (19km / 2) = 9.5km + 2km = 11.5km


Section-ServiceKm Trip 2: 19km

Coupling
(in associated time profile of the trips)

Illustration 205: 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 Vehicle journey, 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.

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.

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.

648

PTV AG

Chapter 7.6: PuT operating indicators

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 output attribute of the vehicle
journey section are equally added up and allocated to the AH output attribute for each level.

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.

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.
In the example Example_LLE.ver the network object vehicle journey section has the userdefined 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.

Main line
Line
Line route
Time profile
Vehicle journey
Vehicle journey item

Main lines do not exist


Train: = 2 * 8,05 GE/km = 16,1 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 1 >; TP1: 19 * 0,38 GE/km = 7,22 GE/km
Train 1 <; TP1: 19 * 0,38 GE/km = 7,22 GE/km
Trips 58 to 95 (38 trips): 0,38 GE/km each
Trips 58 to 95, each exactly 1 VJI: 0,38 GE/km each

Illustration 206: Extended projection of attributes

PTV AG

649

Chapter 7: Operator model PuT

650

PTV AG

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 651)


Calculation of noise emission levels in accordance with RLS-90 (see User Manual, Chpt.
8.4, page 1250).
Noise-Emis-Nordic (see "Noise volume" on page 651).
Calculation of noise emission levels in accordance with Nordic Council of Ministers (1996)
(see User Manual, Chpt. 8.4, page 1250).
Pollution-Emis (see "Air pollution emissions" on page 654).
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 1253).

The Visum add-on module HBEFA allows you to calculate emission values in Visum by link,
territory or network-wide. 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 657).

Subjects

8.1

Noise volume
Air pollution emissions
Emission calculation according to HBEFA 3.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-EmisNordic 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.

PTV AG

Lm(25 ) = 37 ,5 + 10 lg [M (1 + 0 ,082 p )]

M = relevant hourly traffic volume (car/h)


p = relevant HGV proportion in percent of total traffic (above 2.8 t total permissible weight)

651

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.
Note: The correction factor DE which takes absorption characteristics of reflecting areas
into account is not calculated.

The final result for every active link is the emission level Lm,E which is calculated through
an addition using equation (6), RLS-90.
Lm ,E = Lm + Dv + DStrO + DStg

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 different input attributes (table 257). To
understand these input attributes please refer to the explanations and illustrations in the RLS90. The output value Noise is returned as a result.
Attribute

Description

Share of HGV
(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

SurfaceType
EWS surface type
(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 653).
Default: 1
Value range: 1 to 9

Noise
(Output)

Mean emission level Lm,E of long and straight roads in [dB].

Table 257: Link attributes for noise calculations

652

PTV AG

Chapter 8.1: Noise volume

Parameters file RLS.DAT


*Road surface
permissible maximum speed
*
30 km/h
40 km/h
* non-porous
*cast-asphalt, asphalt concrete
* Type 1
0
0
*
* porous cast-asphalt
* Concrete
* Type 2
1.0
1.5
*
* Paving with
* level surface
* Type 3
2.0
2.5
*
*other paving
*
* Type 4
3.0
4.5
*
* ZTV Concrete 93
* with steel brush stroke
* Type 5
0
0
*
* ZTV Concrete 93
* without steel brush stroke
* Type 6
0
0
*
* Asphalt concrete 0/11
* Mastix asphalt
* Type 7
0
0
*
* open porous asphalt
* Grain 0/11
* Type 8
0
0
*
* open porous asphalt
* Grain 0/8
* Type 9
0
0

50 km/h

>= 60km/h

2.0

2.0

3.0

3.0

6.0

6.0

1.0

-2.0

-2.0

-4.0

-5.0

The values apply to the correction penalties per surface type.


The illustration 207 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 (see User Manual, Chpt. 8.5, page 1251).

PTV AG

653

Chapter 8: Environmental impact model and HBEFA

Illustration 207: Illustration of noise volume as link bars

Note: To illustrate the noise volume in traffic networks, we recommend a classification


according to the DIN standard 18005 Part 2 09.91.

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.

654

PTV AG

Chapter 8.2: Air pollution emissions

*
*
*
*
*
*
*
*

Input file for flexible emission formulas for Switzerland 1990


They are polynome to the 5th degree.
a + bx + cx2 + dx3 + ex4 + fx5
a

bx

(the numbers are exponential)


(x is the speed of cars or HGVs)
+

cx2

dx3

ex4

fx5

NOx CAR
0.75860

2.8004e-2 -9.9187e-4

1.4276e-5 -5.6655e-8

0.0

* NOx HGV
* CO

CAR

* CO

HGV

* HC

CAR

* HC

HGV

24.216

-0.70194

1.5878e-2 -1.5996e-4

16.425

-0.38357

2.8706e-3 -4.5425e-6

45.380

-3.0729

9.7880e-2 -1.6116e-3

2.2155

-6.6593e-2 8.7930e-4

-5.1330e-6
2.3153e-3

7.1751e-7

0.0

0.0

0.0

1.3138e-5 -4.1410e-8
1.1381e-8

46.490

-3.7859

0.13382

101.80

-3.0309

4.4557e-2

-2.8928e-4 7.7300e-7

1980.4

-87.564

2.9120

-5.0701e-2 4.3285e-4

0.0

1.9258e-5 -6.1410e-8

* SO2 CAR
0.0

* SO2 HGV
-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 208:
CO emission volume in g/km
20,0
HGV (same values for all years)

18,0
16,0
14,0

Car 1990

12,0
10,0
8,0

Car 1992
6,0
4,0
2,0

Car 2000

0,0
0

10

20

30

40
50
60
Speed km/h

70

80

90

100

110

Illustration 208: 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 258 are output as output values.

PTV AG

655

Chapter 8: Environmental impact model and HBEFA

Attribute

Description

Share of HGV Relevant HGV share in percent of total traffic (above 2.8 t total permissible weight)
(Input)
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 258: Pollutant-Emis link attributes

The illustration 209 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 1254).

Illustration 209: Display of nitrogen monoxide volumes as link bars

Note: For the display of pollution emissions, we recommend the use of classified values.

656

PTV AG

Chapter 8.3: Emission calculation according to HBEFA 3.1

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 1256).

8.3.1

Fundamental principle
The HBEFA-based emission calculation procedure allows you to calculate emission values
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."
Note: The complete HBEFA Handbook is available on the website www.hbefa.net.

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)
Note: You can calculate the dynamic variant, if volumes are available for individual analysis
time intervals.
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 log file.

PTV AG

657

Chapter 8: Environmental impact model and HBEFA

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 Urban:
HBEFA link class

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.
Gradient class:
The gradient class results from the attribute Gradient based on the following classification:
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%

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.
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.
Static traffic situation (i. e. without the LOS share):
The urban/rural classification results directly from the link attribute 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):

658

PTV AG

Chapter 8.3: Emission calculation according to HBEFA 3.1

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

PTV AG

Element

Description

CO

carbon monoxide

Fuel

fuel consumption

Gasoline

fuel consumption

Diesel

fuel consumption

PM

particle matters

HC

hydrocarbons

659

Chapter 8: Environmental impact model and HBEFA

Element

Description

NOx

nitrogen oxide

CO2 reported

carbon dioxide "reported", i.e. without the biofuel share in the fuel

CO2 total

carbon dioxide "total", computed as total CO2 from fuel consumption

PN

Particle number

Group 2: Complementary measurement programs and literature


Element

Description

Pb

lead

benzene

benzene

CH4

methane

SO2

sulfur dioxide

NO2

nitrogen dioxide

NMHC

non-methane hydrocarbon

Group 3: Indicative literature references


Element

Description

NH3

ammoniac

N2O

nitrous oxide

Note: The emission factors of the pollutants SO2, Pb and CO2 reported are country specific
because they depend on the composition of the fuel. So far, only values for Germany can be
calculated in Visum.

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
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.

660

PTV AG

Chapter 8.3: Emission calculation according to HBEFA 3.1

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.
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 AP,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.

PTV AG

661

Chapter 8: Environmental impact model and HBEFA

662

PTV AG

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

9.1

EWS Basics
EWS link attributes
EWS Costs
EWS Cost-benefit analysis

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 noninvestment 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.

PTV AG

663

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


Cost annuities

Time of evaluation

l u a t i o n

p e r

Benefit annuities
Discounting

Investment costs in the year of the due date

i o d

Benefit annuities

20 years

Benefit for a
representative year

Accumulation

E v a

Illustration 210: 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 668)).
As a start the investment costs (EWS module: costs in the year of the due date; (see "EWS
Costs" on page 668)) 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 668)). 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.

664

PTV AG

Chapter 9.1: EWS Basics

Cost-benefit analysis
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)
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 664). 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.

PTV AG

Running cost (EWS-97, pp. 29, 5.2)

665

Chapter 9: Economic assessment according to EWS

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
additional maintenance costs for the whole study network (see "EWS Costs" on
page 668).
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.
Notes: Working with Visum, users should pay attention to all differences between the
EWS program module and EWS guidelines. If there are any questions, please contact the
PTV Vision Support.
The application of the EWS add-on module requires the detailed knowledge of EWS-97.
Gained results should be verified through plausibility checks.

9.2

EWS link attributes


EWS-specific link attributes

The table 259 shows the EWS link attributes.


Attribute

Description

DistanceBuilding
EWS building distance
(Input)

Distance of kerb to building properties [m]


Default: 0
Value range: 0.00 to 1,000,000.00

BuildingType
EWS building type
(Input)

Type of building properties


0 = none
1 = open
2 = closed
Default: 0

BuildingHeight
EWS building height
(Input)

Minimum average height of house fronts [m] (cf. EWS-97, equation 70)
Default: 0
Value range: 0.00 to 1,000.00

Table 259: EWS-specific link attributes

666

PTV AG

Chapter 9.2: EWS link attributes

Attribute

Description

Residents
EWS residents
(Input)

Number of residents concerned


Default: 0
Value range: 0 to 100,000

EWSClass
EWS class
(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

SidewalkWidth
EWS sidewalk width
(Input)

Sidewalk width for actual state [m]


Default: 0
Value range: 0.00 to 99.99

Curvature
EWS curvature
(Input)

Curvity as the total of all angles per kilometer [gon/km]


Default: 0
Value range: 0 to 10,000

CyclelaneWidth
EWS cycle lane width
(Input)

Cycle track width for actual state [m]


Default: 0
Value range: 0.00 to 99.99

SidewalkWidthFuture
EWS sidewalk width
future
(Input)

Sidewalk width for future state [m]


Default: 0
Value range: 0.00 to 99.99

CyclelaneWidthFuture
EWS cycle lane width
future
(Input)

Cycle lane width for future state [m]


Default: 0
Value range: 0.00 to 99.99

Table 259: EWS-specific link attributes

Further link attributes


The following link attributes are also used with the Visum Environment add-on module.

Slope [%]

Surface type

Longitudinal gradient of the lane (positive: uphill; negative: downhill).


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).

PTV AG

667

Chapter 9: Economic assessment according to EWS

Note: In Visum immission height is not calculated according to EWS-97, equation (67),
but directly input by the user.
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.
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.

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.

668

PTV AG

Chapter 9.4: EWS Cost-benefit analysis

9.4

EWS Cost-benefit analysis


Visum 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 EWS
calculations (see User Manual, Chpt. 9.8, page 1277).
Then all EWS calculations are output as annual values in a result table, see illustration 211.

Illustration 211: 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 668) of comparison case and
planned case and their cost difference.
Investment costs (annuities; (see "EWS Costs" on page 668)) of comparison case and
planned case and their cost difference.
Total costs, the sum of investment costs and running costs of comparison case and
planned case and their cost difference.
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 in illustration 211:
Share % CO 2 =

PTV AG

CBRCO 2
0.94
=
= 6.56
CBRTotal 14.36

669

Chapter 9: Economic assessment according to EWS

CBR, overall cost-benefit ratio and relative cost-benefit ratio of the individual benefit
components, for example according to table in illustration 211.

CBRTotal =

UtilityTotal
7.945 Mio. DM / a
=
= 14.36
CostDiffTotal 0.553 Mio. DM / a

CBRCO 2 =

UtilityCO 2
0.521 Mio. DM / a
=
= 0.94
CostDiffTotal 0.553 Mio. DM / a

The cost-benefit ratio allows a ranking of the different planning variants: construction
worthiness if CBRTotal 1.

670

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 Geodatabase (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 72)


Showing and hiding layers (see User Manual, Chpt. 12.2.2, page 1402)
Freely definable coloring for network objects (see User Manual, Chpt. 12.2, page 1400)

Subjects

10.1

Connection to the Personal Geodatabase and GIS objects


Shape files as a GIS interface
Intersect
Coordinate systems
Processing the network display with graphic objects
GPS tracking

Connection to the Personal Geodatabase and GIS objects


Visum can temporarily connect itself with an ESRI Personal Geodatabase (PGD) or a shape
file. This function can be useful for example, when a traffic modeler working with Visum,
connects to a Personal Geodatabase on the computer of a land use planner. The traffic
modeler can then take the required data from the Personal Geodatabase of the land use
planner by means of intersection (see "Intersect" on page 677) and then cut the connection.
This process bypasses the need to import the file back to Visum.
Note: To be use this function, you need a license for the ArcGIS program.
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 72), 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

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:

PTV AG

671

Chapter 10: GIS functions

For each selected Feature Class of the Personal Geodatabase, 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 Geodatabase connection:

10.2

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.

Shape files as a GIS interface


Shape files are a data format for geodata, which are used in most GIS. The data format is
especially suitable for the data exchange between Visum and GIS. With Visum you can read
and save shape files.
Note: To save shape files you need the Shapefile converter. add-on.
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.11.2, page 1653).

Shape files can contain points, lines or polygons (surfaces). Only one type of element can be
contained in a shape file.
Note: A technical description of the data format can be found on the Internet at www.esri.com/
library/whitepapers/pdfs/shapefile.pdf.

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 260.

672

PTV AG

Chapter 10.2: Shape files as a GIS interface

Link, Screenline,
Connector
Point
Polyline
Polygon

Zone, Main zone, Territory,


Main node
X

Node, Detector, Count


location, Stop, Stop point
X

POI
X
X

Table 260: Reading shape files in Visum network objects

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.
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 (see User Manual, Chpt. 2.12.14,
page 255), create 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). The illustration 212 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.
Note: When loading polygons from shape files (e.g. as zone polygons or POIs for a
background image), you can optionally activate normalization of the loaded surface data (see
"Multi-part surfaces" on page 114). This is required if you want to use the loaded polygons to
perform geometrical operations, such as surface calculation or intersections, as otherwise
the results might be falsified. If you merely wish to display polygons, then normalization is not
required.

PTV AG

673

Chapter 10: GIS functions

Illustration 212: Source and target attribute allocations

Example applications

Reading shape files with a road network as links in Visum. In Visum a routing-enabled link
network is then available.
Note: The links have to first be enabled for transport systems.

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. The illustration 213 shows an
example, where two shape files were integrated as a background with land use for residential
and commercial areas.

674

PTV AG

Chapter 10.2: Shape files as a GIS interface

Illustration 213: Land use from two shape files as background

10.2.2

Exporting shape files


Note: Exporting shape files is only possible with the Shapefile converter add-on.
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 network object type you select, 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.

PTV AG

675

Chapter 10: GIS functions

The table 261 shows in which shape types the Visum network objects are illustrated.
Point
Nodes

Polyline

Polygon

Main nodes

Main node centroids

Stop points

Stops

Links

Zones
Zone centroids

X
X

Main zones
Main zone centroids

X
X

Territories
Territory centroids

X
X

Line routes

Screenlines

Connectors

Count locations

Detectors

POIs

Table 261: Illustration of Visum files of shape types

When exporting shape files, the following special cases have to be noted.

676

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.

PTV AG

Chapter 10.3: Intersect

10.3

Intersect
The "Intersect" functionality known from GIS describes the overlap of two subject levels of the
same area section with the aim of gaining new information. This can be used to link two
network objects which overlap each other (intersection) and saves the thus resulting
information in an attribute. To create a demand model, GIS structure data (such as the number
of employees or the number of pupils) can for example be read in POI polygons 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.
The intersection area of two objects results from the spatial overlapping of both objects. The
illustration 214 shows examples of overlapping network objects.

Illustration 214: Examples of overlapping network objects

Use cases
A typical use case for an intersection is the data import from a GIS.

PTV AG

There are land use data in GIS

677

Chapter 10: GIS functions

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 Geodatabase. 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.

Number of boarding PuT passengers per zone (table 262)


Number of inhabitants in the catchment areas of line routes (table 263)
Number of inhabitants in the catchment areas of stops (table 264)
Vehicle kilometers within territories (table 265)
Number of the zone where the stop point lies (table 266)
Numbers of the stops within a zone (table 267)
Average number of boarding PuT passengers at the stops of a zone (table 268)

Intersecting zones and stop points: The passengers in a zone are calculated from the ZoneAddValue1 =
Sum of passengers at all stop points in the zone polygon.

Table 262: Calculating the number of PuT passengers per zone

678

PTV AG

Chapter 10.3: Intersect

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 263: Calculating the number of inhabitants in the catchment areas of lines

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 264: Calculating the number of inhabitants in the catchment areas of stops

PTV AG

679

Chapter 10: GIS functions

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.

Table 265: Calculating the vehicle kilometers within territories

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). If you want to determine all
zones in which the stop point lies, use a target attribute of the type Text and Concatenate as aggregate
function.

Table 266: Calculating the zone number where a stop point lies

680

PTV AG

Chapter 10.3: Intersect

Intersecting zones and stops: which stops lie within a zone. As target attribute, a user-defined attribute
of the type Text is used, to which a concatenated list of the numbers of the stops will be saved.

Table 267: Determination of the numbers of the stops that lie within a zone

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 262), but the average number of PuT passengers
at the stops of a zone, proceed as described in table 268.

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 268: 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.

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.

PTV AG

681

Chapter 10: GIS functions

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 twodimensional 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 of radius to a point of obj to the particular object. Radius = 0 results in the obj itself.
In the case of polygon objects, polygons plus their buffers are intersected.

Intersections
The intersection procedure determines source objects that overlap with a specific target object.
The attribute data of such a target object is aggregated according to the option selected and is
then assigned to the target object. The available aggregate functions and their effect depend
on the data types of the source and target attributes (table 269). The respective aggregation
functions are available in the combinations of the table only.
Aggregate function

Sum

Mean value

Data type target


attribute

Data type source


attribute

Effect
Sum source attribute values,
weighted by overlapping area,
where applicable

Numerical

Numerical

Text

Numerical

Numerical

Numerical

Text

Numerical

Numerical

Numerical

Text

Numerical

Text

Text

Minimum / Maximum

Number

Concatenate

Histogram

Numerical

Numerical

Text

Numerical

Text

Text

Text

Numerical

Text

Text

Text

Numerical

Text

Text

Mean value of the source


attribute values, weighted by
overlapping area, where
applicable
Minimum / Maximum of the
source attribute values, weighted
by overlapping area, where
applicable
Minimum / Maximum of the
source attribute values
(comparison of the strings)

Number of overlapping objects

Concatenated list of the source


attribute values
Concatenated list of the source
attribute values and the number
of their occurrence at
overlapping objects

Table 269: Available aggregate functions for intersection

682

PTV AG

Chapter 10.3: Intersect

For numerical source and target attributes, you can either choose to use the full source
attribute data or a share of the data that is proportional to the overlapping area with the source
object. This section describes the results of the two options.
Note: To determine the number of source objects per target object, or the ID-number of a
surface object overlapping with another surface object, choose the full source attribute data.
In nearly all other cases, choose the proportional share of the source attribute data.
There are three types of intersections:

Surface with surface


The intersection P1 P 2 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 the 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.

Share( P1, P 2)=

Content ( P1 P 2)
Content ( P 2)

If a buffer > 0 is assigned to a point or line object, it turns into a polygon.


When you choose to use a share of the source attribute data proportional to the area
overlapping with the source object, this share is calculated as follows:

0
Share( Po int p, genPoly pg )=
1

p pg
p pg

Share( genPoly pg , Po int p ) = Share( Po int p, genPoly pg )


Share( Link l , genPoly pg ) =" Share of length l in pg"

Share( genPolyline l , genPoly pg )=

Share(l , pg ) Length(l )
Length(l )

Links ll

Links ll

Share( genPoly pg , genPolyline l )


PTV AG

683

Chapter 10: GIS functions

= Share( genPolyline l , genPoly pg )


Share( genPoly pg1, genPoly pg 2)=

Content ( pg1 pg 2)
Content ( pg 2)

When you choose to use the full source attribute data, the share is 100%, if source and target
object overlap (including buffers). Otherwise it is 0%. In this case the size of the overlapping
area is not relevant.
Intersection then results in:

TAttr (t arg obj )= Aggr (OAttr (origobj ) Share( P1, P 2) )


origobj

with P1 = buffer(targetobj, targetradius), P2 = buffer(sourceobj, sourceradius).


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.
The following examples show the effect of the intersect operation in Visum.

(1)

(2)

(3)
Illustration 215: Intersecting three polygon objects with a link buffer

In illustration 215, surfaces are intersected with surfaces. The intersection of two polygons is
defined as usual.

684

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)

PTV AG

Chapter 10.3: Intersect

Illustration 216: Intersecting point objects with a polygon

In illustration 216, 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 217: Intersecting point objects with a buffer polygon

In illustration 217, 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%.

2
1

3
4

Illustration 218: Intersecting point object buffers with polygons

PTV AG

685

Chapter 10: GIS functions

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 illustration 218, 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 1283).
The coordinate system can be changed in Visum. You can automatically transform the
coordinates of the current network (see User Manual, Chpt. 10.1.1, page 1283).
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.
You can find them in the directory ...Program files\PTV Vision\PTV Visum 13\Exe\Projections.
This file format is Well-Known-Text-Format in ESRI version.
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.
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 shows two projection files for a planar and a geometric coordinate
system in Visum.

686

PTV AG

Chapter 10.4: Coordinate systems

Example for planar coordinate system (WGS 1984 UTM Zone 48N.prj)
PROJCS["WGS_1984_UTM_Zone_48N",
GEOGCS["GCS_WGS_1984",
DATUM["D_WGS_1984",
SPHEROID["WGS_1984",6378137,298.257223563]],
PRIMEM["Greenwich",0],
UNIT["Degree",0.017453292519943295]],
PROJECTION["Transverse_Mercator"],
PARAMETER["False_Easting",500000],
PARAMETER["False_Northing",0],
PARAMETER["Central_Meridian",105],
PARAMETER["Scale_Factor",0.9996],
PARAMETER["Latitude_Of_Origin",0],
UNIT["Meter",1]]

Table 270: Planar coordinate system

Example for geographic coordinate system is the German Main Triangle Network (Deutsches
Hauptdreiecksnetz.prj):
GEOGCS["GCS_Deutsches_Hauptdreiecksnetz",
DATUM["D_Deutsches_Hauptdreiecksnetz",
SPHEROID["Bessel_1841",6377397.155,299.1528128]],
PRIMEM["Greenwich",0],
UNIT["Degree",0.017453292519943295]]

Table 271: Geographic 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).
Visum manages coordinate systems in the following file types: Depending on the file type,
coordinate information is saved or imported differently.

PTV AG

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,
*.accdb
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.4.7,
page 54).

687

Chapter 10: GIS functions

10.5

File type

Write

Read

*.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
(see User Manual, Chpt. 10.4.1, page 1296).

*.inp
Vissim network

The coordinates are written to the not applicable


*.inp file without further
transformation.

*.hgr
Background file

not applicable

Background files are not adjusted.

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:

10.5.1

Inserting texts (see "Texts" on page 688)


Automatic creation of a legend (see "Legend" on page 688)
Inserting polygons (see "Polygons" on page 694)
Inserting background graphics (see "Backgrounds" on page 689)

Texts
Texts serve to additionally label the network display. There are two text types:

Background texts
Texts which are added to the network display
Legend texts
Texts which are inserted into a legend

Note: Graphic texts are network-independent graphic objects and therefore be differentiated
from labels of network objects and labels for plot output.

10.5.2

Legend
Using the Legend function, in the Visum network display or schematic line diagram, you can
show additional, descriptive and explanatory information. To do so, in the legend, select the
objects you want to show and specify the display style (see User Manual, Chpt. 10.9,
page 1325). In addition, in the legend footer, you can insert user-defined information, e.g.
diagrams created with external programs (illustration 219).

688

PTV AG

Chapter 10.5: Processing the network display with graphic objects

Illustration 219: Legend with user-defined texts

10.5.3

Backgrounds
Including backgrounds allows you to improve network display and orientation as well as add
graphic 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. Graphic background data can be provided in
different ways. You can insert existing files in various graphic or GIS formats as a background
for your network display. Vector graphics, e.g. *.shp or *.dxf as well as raster graphics, e.g.
*.jpg, *.bmp or *.sid, are supported.
Besides existing graphic files, you may also use city maps or aerial and satellite images,
provided by map services on the Internet, as your background image. Map providers offer highresolution aerial and satellite images as well as detailed city maps for many regions. Apart from
commercial offers such as Microsoft Bing Maps (see "Backgrounds by Bing Maps" on
page 691), there is free data available by map providers, e,g. OpenStreetMap, that you may
use under certain conditions. You can download the map data automatically and insert it as
your background. If you have a permanent Internet connection, you can show the Background
graphic layer as an alternative to a statically embedded background. The graphic layer
contains the background graphics that match a network section. They are called dynamically
by map providers on the Internet (see User Manual, Chpt. 10.7.1.1, page 1309).

PTV AG

689

Chapter 10: GIS functions

Note: Using data from map providers is subject to license terms and conditions. Please learn
about these terms in advance and consider them when working on projects and sharing
results.

10.5.3.1 Dynamic background map


The graphic layer Background map dynamically embeds maps and aerial images of map
services into network display. The data matching the current network section is shown at the
respective zoom level. You can optionally show the map data in shades of gray or pale colors,
so as to not overpower the network display (see User Manual, Chpt. 10.7.1.1, page 1309).
Compared to static backgrounds, the display is controlled exclusively via graphic parameters
and options. There are no additional functions for administration. The data are not saved to the
system, so that this functionality requires a permanent Internet connection.
To use it, you need to select a coordinate system for the network. You can use any of the
coordinate systems defined in Visum. The background maps are transformed to the coordinate
system selected in Visum and are then displayed. If in Visum you select the coordinate system
used by the map provider, no transformation is required and the background map can be
displayed quicker. Most map services use a special type of Mercator projection (see
"Coordinate systems" on page 686). The projection files delivered with Visum include this
coordinate system as so-called WGS 84 - Pseudo-Mercator (adapted EPSG 3857) (see User
Manual, Chpt. 10.1.1, page 1283). When you start a new session or open a new network, this
coordinate system is your default setting. The definition of this coordinate system largely
corresponds to the one defined in EPSG 3857, however, with minor changes that allow it to be
used with common map services and Visum.
By default, Visum provides several map services in the Graphic parameters. You may also
define map services that can be used alternatively (see User Manual, Chpt. 10.7.1.3,
page 1311).
To set up a user-defined map service, you need to know the URL structure and projection this
service uses to call map sections. You then enter a URL template for the service. It contains
several wildcards, e.g. for map section and zoom level parameters. When calling a specific
map section, Visum replaces the wildcards with the current data (see User Manual, Chpt.
10.7.1.3, page 1311). In the Graphic parameters and version file, map services are only
referred to via their names. User-defined map services must have the same name on all
computers using them. You can ensure this by exchanging a file containing the user settings
(see User Manual, Chpt. 1.8.2, page 69). This makes sure that changes made to the
configuration data of user-defined map services become effective in all the following Visum
sessions, irrespective of the version file used.

10.5.3.2 Statically embedding background images by map providers


Besides using the dynamic graphic layer Background map, you can embed data provided by
map services as static backgrounds. Compared to the Background map, the downloaded data
is saved to the hard drive, so that it is available without a permanent Internet connection (with
the exception of Bing Maps).

690

PTV AG

Chapter 10.5: Processing the network display with graphic objects

Map providers offer maps and aerial photos in a pre-arranged tile configuration. They come in
a graphic format (e.g. JPEG or PNG) and in a uniform size that allows for several detail levels.
The data are available in a projected form, usually in Mercator projection (see "Coordinate
systems" on page 686). Visum automatically downloads the tiles for the current network
section (in the detail level selected) from the map provider, converts the data into the
coordinate system format used in Visum and integrates the data as background objects.
Depending on the size of the current network section, the original tiles are combined to several
large files. The background files generated are saved to special background folders in the
project directory. The folder structure is shown in the Administration tab, in the Background
window. You can use the Administration function to control the visibility of network
backgrounds (see User Manual, Chpt. 10.7.4, page 1315).
Note: To use background images of map providers you need to set a coordinate system for
your network (see User Manual, Chpt. 10.1.1, page 1283). Background images of freely
accessible map providers are downloaded once and saved to the computer. The embedded
maps are not automatically updated or adapted to a different network section. This is why the
use of freely available map data does not require a continuous Internet connection. If you
want to update background images, delete the existing ones and embed new ones.

10.5.3.3 Backgrounds by Bing Maps


In addition to the maps by freely available map providers, Visum provides the possibility to use
high-resolution aerial pictures and maps by Bing Maps as background graphics. Due to the
terms of use of Bing Maps, these data cannot be stored permanently. Therefore, Visum only
saves the sections and zoom levels for which backgrounds of Bing Maps were embedded in
the graphic parameters and in the version file, and reloads them from Bing Maps each time
they are used. This ensures that the latest available map material is always used. Different
functionalities for the administration of backgrounds are thus not available for Bing Maps
backgrounds.
Notes: Backgrounds by Bing Maps are only available to customers with maintenance
agreements.
In order to use Bing Maps backgrounds, a coordinate system must be set for the network (see
User Manual, Chpt. 10.1.1, page 1283). Unlike to the use of background images of freely
accessible map providers (see "Statically embedding background images by map providers"
on page 690), you need an Internet connection for each session. The update of the
backgrounds is automatic.

10.5.3.4 Background images from graphic and GIS files


Backgrounds in graphics formats (table 272) 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. The illustration 220 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 221.

PTV AG

691

Chapter 10: GIS functions

Illustration 220: Visum network display without background

Illustration 221: Visum network display with background

692

PTV AG

Chapter 10.5: Processing the network display with graphic objects

10.5.3.5 Supported background file formats


The table 272 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 a 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 672).

*.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 272: Background formats supported by Visum

PTV AG

693

Chapter 10: GIS functions

10.5.3.6 Automatic 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.
Note: World files do not contain a reference to a coordinate system.
Each World file has six rows. The table 273 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 B 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

32.0
0.0
0.0
-32.0
691200.0
4576000.0

Table 273: 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.

10.5.4

Polygons
The polygons of Visum are graphic objects available for free design of your drawings. Polygons
can be edited in many ways:

694

Drawing lines or areas


Choice of color
Position of lines and line types
Patterns for areas

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 1329).
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 1400). The position acquired
by the GPS receiver (length, width) will always be transferred into the current projection of the
network (see "Coordinate systems" on page 686). 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.

PTV AG

695

Chapter 10: GIS functions

696

PTV AG

11

Interactive analyses
Visum offers various functionalities that allow you to evaluate your traffic model interactively.
These can be used to analyze both PrT and PuT. The following interactive analyses are
available.
Flow bundles

Filtering paths obtained through assignment according to different criteria (e.g.


all paths traversing a specific link)

Isochrones

Analysis of the accessibility of network objects. Network objects which can be


accessed from one or several network objects within the same time are
highlighted in the same color (e.g. all locations that can reached from a specific
node within 5 minutes on foot).

Shortest path search

Search for the shortest path between zones, nodes or main nodes, according to
different criteria (e.g. distance)

Subjects

11.1

Flow bundles
Isochrones
Shortest path search

Flow bundles
Flow bundles are used to filter and graphically display loaded paths (obtained through
assignment) according to various 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. In
the following section, you will learn about how to use the individual filter criteria. The
illustration 222 displays the principle of the flow bundle. The left figure shows all paths found in
the assignment. The right figure shows the paths traversing the highlighted link.

PTV AG

697

Chapter 11: Interactive analyses

All PrT paths (displayed as volume bars)

Filtering of all PrT paths traversing the highlighted


link by defining a flow bundle

Illustration 222: The flow bundle as path filter

The flow bundle can be displayed graphically in the network editor (see User Manual, Chpt.
11.1.2, page 1345) or output as a list (see User Manual, Chpt. 12.1.6, page 1380). Using PuT
assignment as an example, illustration 223 displays the flow bundle paths in the PuT path legs
list. In the graphical 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 223: Display of the flow bundle paths in the PuT path leg list

Note: To display a flow bundle, you first have to calculate an assignment and save its paths.
You can save paths in the PrT (see User Manual, Chpt. 5.1.2, page 975) and in the PuT (see
User Manual, Chpt. 6.1.1.2, page 1072).

698

PTV AG

Chapter 11.1: Flow bundles

The flow bundle type is defined via the network object type selected:

Flow bundles based on nodes, main nodes, stops, stop points or stop areas (highlighting
nodes, main nodes, stop points, stop areas or stops)
Link flow bundle (highlighting links)
Zone and main zone flow bundle (highlighting zones or main zones)
Traffic type-based flow bundle (by setting specific links or network objects of the line
hierarchy, i.e. lines, line routes, etc., passive)

The flow bundle can be created by highlighting one or more objects of a network object type. It
can also be determined by any combination of highlighted network objects of different network
object types (see "Combining flow bundle criteria" on page 706).
Notes: If a flow bundle is active, its demand can be saved as a flow bundle matrix.
The flow bundle considers the active settings of the OD pair filter. This allows you to perform
flow bundle analyses that are additionally defined via the zone type (e.g. for internal zones
only).

11.1.1

Flow bundle definition through selection of network objects


Flow bundles can be defined through the selection of one or several network objects.
Depending on the network object type, specific settings can be made.

Node flow bundle (PrT and PuT)


The node flow bundle lists all paths traversing the selected node(s).
For PrT and PuT, select the demand segments for each node whose paths you want to use for
flow bundle calculation. The assignment results and thus the paths of each demand segment
are listed separately.
For PuT, you additionally have the option of limiting the PuT supply (e.g. to certain lines) (see
"PuT supply filter" on page 705).
In the following example (illustration 224), the flow bundle contains all paths that traverse node
100,001, using line 002. There may be path legs shared with other lines before or after the leg
via node 100,001 with line 002, see illustration 225.

PTV AG

699

Chapter 11: Interactive analyses

Illustration 224: PuT node flow bundle with additional filter criteria for lines

Illustration 225: Some of the paths which traverse node 100001 and use line 002

Main node flow bundle (PrT only)


The main node flow bundle works analogous to the node flow bundle. It outputs paths
traversing the selected main node(s). You need to select the demand segments whose paths
you want to use for flow bundle calculation.

700

PTV AG

Chapter 11.1: Flow bundles

Link flow bundle (PrT and PuT)


The link flow bundle lists all paths traversing the marked links. In PuT, some links might only
be traversed partially, due to link stop points. The determining factor for the flow bundle is the
middle of the link: a link is considered traversed, if a path traverses the middle of the link.
You have to select the demand segments, both in PrT and PuT, whose paths you want to use
for flow bundle calculation.
Just like for the nodes, for PuT you additionally have the option of limiting PuT supply (e.g. to
certain lines) (see "PuT supply filter" on page 705).

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 traversing each of the selected network objects. You can limit the
passenger types for each network object selected:

Origin boardings (B): A path is displayed in the flow bundle, if passengers board at the
network object selected, i.e. if there is no other PuT partial leg before boarding.
Destination alightings (A): A path is displayed in the flow bundle, if passengers alight at the
network object selected, i.e. if there is no other PuT partial leg after alighting.
Transfers (T): A path is displayed in the flow bundle, if passengers traverse at the network
object selected. This can be at a boarding or an alighting point of transfer.
Through passengers with stop (W): A path is displayed in the flow bundle, if there is a stop
at the selected network object and passengers remain on board. The line stops at the
network object without passengers alighting or transferring.
Through passengers without stop (N): A path is displayed in the flow bundle, if passengers
pass the selected network object without stopping. In this case the line does not stop.

Just like for nodes and links, you additionally have the option of limiting PuT supply (e.g. to
certain lines) (see "PuT supply filter" on page 705). For transfers, you can set separate filters
for alighting and boarding passengers.

Zone and main zone flow bundle (PrT and PuT)


Flow bundles for the network object types zone and main zone list all paths starting or ending
at the selected network object. Accordingly, you specify whether you want to filter by origin
traffic or by destination traffic.

Origin traffic: all paths starting in the selected zone or main zone
Destination traffic: all paths ending in the selected zone or main zone
Origin and destination traffic: all paths that start or end in the selected zone or main zone

In addition, you have to select the demand segments, both in PrT and PuT, whose paths you
want to use for flow bundle calculation.
Just like for the nodes, for PuT you additionally have the option of limiting PuT supply (e.g. to
certain lines) (see "PuT supply filter" on page 705). Limiting PuT supply applies to the first or
last PuT path leg, depending on whether you have filtered by origin or destination traffic.

11.1.2

Flow bundle definition through selection of traffic types


By setting links or network objects of the line hierarchy (lines, line routes, etc.) to active or
passive, you can filter paths of the flow bundle by traffic type (internal traffic, origin traffic,
destination traffic, through traffic, external traffic or bypassing internal traffic).

PTV AG

701

Chapter 11: Interactive analyses

In the following example, Lynnwood town center through traffic is illustrated by the traffic typebased flow bundle. Only those paths are displayed in the flow bundle that start and end in an
external zone, but between the zones traverse the city center. In illustration 226, the flow
bundle is displayed for the through traffic and for the flow bundle path from external zone 136
to external zone 27.

Illustration 226: Display of through traffic with a flow bundle of active links

Note: To calculate a traffic-type based flow bundle, you need to set at least one link or one
network object of the line hierarchy to passive. To set an object to passive, use the filter (see
User Manual, Chpt. 2.7, page 194) or spatial selection (see User Manual, Chpt. 2.8,
page 217).
In both cases (links or network objects belonging to the line hierarchy), Visum distinguishes
between the traffic types internal traffic, origin traffic, destination traffic, through traffic, external
traffic and bypassing internal traffic. These traffic types partition the number of all paths, i.e.
each path has a unique traffic type.
The following examples refer to a link traffic type flow bundle, for which inner city links have
been set to active and outer city links to passive.

702

Internal trips: Paths used by active network objects only. Example: The flow bundle shows
the paths in the urban area.

PTV AG

Chapter 11.1: Flow bundles

Origin demand: Paths starting with an active network object and ending with a passive
network object. Example: The flow bundle shows all commuter flows from the urban area
to its urban hinterland.
Destination demand: Paths starting with a passive network object and ending with an active
network object. Example: The flow bundle shows all commuter flows from the urban
hinterland to the urban area.
Through traffic: All paths that start and end with a passive object, but use at least one active
object in-between. Example: The flow bundle shows HGV traffic traversing a conurbation.
External trips: Paths that do not use active network objects. Example: The flow bundle
shows traffic bypassing a conurbation.
Bypassing internal trips: Paths that start and end with an active network object, but use at
least one passive network object in-between. Example: The flow bundle shows traffic that
starts and ends in an urban area, but that traverses the urban hinterland, e.g. on a
bypassing road that has a higher speed limit.

The table 274 shows which sequence of links (for a link traffic type flow bundle) or of PuT lines
on path legs of a PuT path (for a PuT line traffic type flow bundle) belongs to which traffic type.
For sequences with more than four objects, there are more variants.
Number of links
or PuT lines
Internal trips

1
a

2
a-a

3
a-a-a

4
a-a-a-a

Origin demand

a-p

a-x-p

a-x-x-p

Destination demand

p-a

p-x-a

p-x-x-a

Through traffic

p-a-p

p-a-x-p or
p-x-a-p

External trips

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 274: Traffic type based on status (active / passive) of links or PuT lines

The abbreviations in table 274 have the following meaning:


a: link or PuT line active
p: link or PuT line passive
x: not relevant whether link or PuT line is active or passive

11.1.2.1 Traffic type flow bundle for active links


You can use traffic type flow bundles for active links for paths of PrT assignments or PuT
assignments, as both path types can be described as a sequence of links.
On PuT paths, links can be traversed with PuT lines, PuT-Aux TSys or PuT-Walk TSys. All
three possibilities are accounted for in the link traffic type flow bundle. Transitions within a stop
or between stop areas and the nodes assigned to them are ignored. So for the distinction
between active and passive areas of a path (including PuT paths), only links are taken into
account.

PTV AG

703

Chapter 11: Interactive analyses

The link traffic type flow bundle also allows you to limit PuT supply, e.g. to specific lines (see
"PuT supply filter" on page 705). Only those links are considered active that have been set to
active and that are used by an active PuT line.
Example: Calculation of the number of passengers using long-distance transportation on a link
corridor (completely or partly):

The link corridor is active, all other links are passive.


Selection of long-distance transportation TSys in PuT supply
Selection of the traffic types internal traffic, origin traffic, destination traffic, through
traffic and bypassing internal traffic

If you want to combine several conditions of the type "Active links" within one flow bundle, you
might have to reverse the active links for the flow bundle, i.e. set all passive links to active and
vice versa. To do so, switch the reference quantity of the link traffic type flow bundle from
"active links" to "passive links" and vice versa.
Example: You want to determine the number of passengers using part of and the entire link
corridor for long-distance transportation, but outside the corridor only use local public transport.

The link corridor is active, all other links are passive.


Add a flow bundle term with long distance transportation TSys as the PuT supply and
the traffic types internal traffic, origin traffic, destination traffic, through traffic and
bypass internal traffic.
Add another flow bundle term with the operator AND and long-distance transportation
TSys as the PuT supply. Choose the traffic type "external traffic". Select "passive links"
as the reference quantity.

By combining two terms that have different reference quantities you can a) filter paths using a
specific PuT supply on active links and b) filter paths using a specific, but different PuT supply
on passive links.

11.1.2.2 Traffic type flow bundle for active PuT lines


The path filter for active PuT lines, line routes, etc. shows the lines or line routes used on a
specific path. For the link traffic type flow bundle, these lines or line routes are links. This
means a PuT path is considered a sequence of active and passive path legs, based on the
active status of the lines, line routes, etc. used on the individual path legs.
You can specify the line hierarchy level of the PuT supply used. The options are: line, line
route, time profile, vehicle journey and vehicle journey section.
The first three network object types are always available. Vehicle journey and vehicle journey
section, however, must be based on timetable-based assignment, for which paths are saved
as connections.
Vehicle journey sections are a special case. They do not carry volumes and there is no unique
vehicle journey section for a path leg, even if a vehicle journey is specified. So when you select
the vehicle journey section level, a PuT path leg is considered active, if it can be fully covered
by active journey sections of its vehicle journey. Visum checks whether there is an active
vehicle journey section for each vehicle journey item on the PuT path leg.
The table 275 depicts the significance of the traffic types after applying a path filter for active
PuT lines. The line filter has been set to active for long-distance trains ("ICE") and to passive
for LRT lines ("RE").
704

PTV AG

Chapter 11.1: Flow bundles

Internal trips
Through traffic
Origin demand
Destination demand

Bypassing internal trips

External trips
Legend
Active PuT supply
Passive PuT supply

Table 275: Significance of traffic types after applying path filter for active PuT lines

For instance, you can perform the following analyses on active PuT lines, using a path filter:
1. Objective: Determine the number of passengers using a long-distance line on at least one
path leg
Only long-distance trains are active. Selection of the network object type lines.
Selection of the traffic types internal traffic, origin traffic, destination traffic, through
traffic and bypassing internal traffic
2. 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
Only long-distance lines are active. Selection of the network object type lines.
Selection of the traffic types origin traffic, destination traffic, through traffic and
bypassing internal traffic
3. Objective: Determine number of passengers who only use vehicle journeys provided by a
specific operator X.
Only vehicle journeys of operator X are active. Selection of network object type vehicle
journeys.
Selection of the traffic type internal traffic

11.1.3

PuT supply filter


For PuT, you can define flow bundle conditions, using the criterion PuT supply. It allows you
to filter paths by network objects that traverse them using a specific transport system, line, etc.
A path is only included in a flow bundle, if it uses the selected PuT supply at the network object.

PTV AG

705

Chapter 11: Interactive analyses

You can choose between different types of PuT supply. The options are: transport systems,
main lines, lines, line routes, time profiles, vehicle journeys and operators. Vehicle journeys
and operators require a timetable-based assignment, for which paths are saved as
connections.
The results obtained with the supply filter depend on the network object type:

nodes and links represent fairly simple examples. The supply filter criteria is met, if the
node or link is traversed by the supply selected. Thereby it is irrelevant whether the paths
traverses the node or link, or starts or ends there.
For zones and main zones, the supply filter filters the first or last path leg - depending on
whether you choose to filter by origin or destination traffic. The options Also PuT-Walk
TSys and Also PuT-Aux TSys are taken into account when Visum checks the connector
node of the path. Consequently, a path starting or ending with a PuT-Walk or PuT-Aux
transport system belongs to the flow bundle, if the respective option has been activated or
the first or last path leg is used for the PuT supply selected.
For stop points, stop areas and stops, Visum distinguishes between two cases:
When determining the number of passengers transferring, you can set supply filters
with the criteria "alighting" and "boarding". This, for instance, allows you to filter all paths
that at a stop switch from long-distance transport to local transport.
Just as for the zones, the options PuT-walk and PuT-Aux play a special role. If you
select "boarding" and the option Also walk TSys, you will also filter by all transfers that
after alighting include a footpath - independent of the PuT supply the passengers
alighted from. The same applies respectively for the option Also Aux TSys.
For all other passenger types, the supply filter is used as described for nodes and links.

When using the traffic type flow bundle conditions for active links, you can additionally filter the
PuT supply. The PuT supply filter is applied directly to the active links. For a traffic type-based
flow bundle, a link on a PuT path is considered active, if both the link itself and the PuT supply
on it are active.

11.1.4

Combining flow bundle criteria


For paths determined by a flow bundle, you can combine several criteria and connect them
with AND THEN or OR. You can also combine PrT criteria and PuT criteria.
The flow bundle in illustration 227, e.g., includes a combination of AND THEN and OR
operators. All paths starting in zone 102 and ending 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 227.

706

PTV AG

Chapter 11.1: Flow bundles

Illustration 227: Paths which start in zone 102 and end in zones 1, 2 or 5

Definition of an AND THEN term


A flow bundle describes all paths that the network objects selected traverse in a specified
sequence. The illustration 228 shows a filter that includes many AND THEN link combinations.
The flow bundle shows all paths that traverse these links in the sequence specified.

PTV AG

707

Chapter 11: Interactive analyses

Illustration 228: All paths which traverse a link section in north direction

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.
Flow bundle conditions for network objects (see "Flow bundle definition through selection of
network objects" on page 699) and flow bundle conditions for traffic types (see "Flow bundle
definition through selection of traffic types" on page 701) can be combined through the AND
operator. In this case, however, the sequence is not specified, as traffic type flow bundles
always refer to the entire path. This is why there are used at the end of AND THEN operations.
Note: You can use the AND operator to combine various traffic type flow bundle conditions or
to combine traffic type flow bundle conditions with network object flow bundle conditions.
The following example shows the flow bundle of illustration 226, for which two additional links
were selected. The flow bundle filters the Lynwood through traffic, traversing the two links in
the sequence specified.

708

PTV AG

Chapter 11.1: Flow bundles

Illustration 229: Through traffic traversing the two links in the sequence specified

Using negated conditions (complement)


Using a negated network object flow bundle condition, you can filter by paths that are not used
by selected network objects.
When combining the negated condition with positive network object flow bundle conditions,
you have various filter options:
1. Objective: all vehicles traversing link 1, but not link 100 afterwards.
First AND THEN operation: link 1
Second AND THEN operation: link 100, complement
2. Objective: all vehicles traversing link 2, but not link 100 before.
First AND THEN operation: link 100, complement
Second AND THEN operation: link 2
3. Objective: all vehicles traversing link 1, then link 2, but do not traverse link 100 in-between.
First AND THEN operation: link 1
Second AND THEN operation: link 100, complement
Third AND THEN operation: link 2
4. Objective: all vehicles traversing link 1, then link 2, but that do not traverse link 100 on their
entire path.
First AND THEN operation: link 100, complement
Second AND THEN operation: link 1

PTV AG

709

Chapter 11: Interactive analyses

Third AND THEN operation: link 100, complement


Fourth AND THEN operation: link 2
Fifth AND THEN operation: link 100, complement

The examples show that the negated network object flow bundle conditions are always
evaluated for an area between positive network object flow bundle conditions. If the sequence
is not important, you might have to add the negated conditions a few times (see example 4).
The sequence is not important for traffic type-based flow bundle conditions. This means that
when you use a complement, it produces a simple logic negation - which corresponds to the
selection of a complementary traffic type set.

Defining an OR operation
Adding an OR operation ends a series of AND THEN operations. Then you can add additional
conditions. A flow bundle describes all paths that fulfill at least one of the filter criteria linked to
an OR operation.
Any number of AND THEN operations can be linked by OR operations. Each path is only
output once with the flow bundle, even if it is found for several AND THEN operations.
The illustration 230 shows how you can simultaneously show a PrT flow bundle and a PuT flow
bundle, using an OR operation. The PrT flow bundle shows all PrT paths traversing nodes
106,062,539 and 106,062,191. The PuT flow bundle shows all PuT paths traversing stops
106,061,623 and 106,063,464.

710

PTV AG

Chapter 11.1: Flow bundles

Illustration 230: Combining flow bundles for PrT and PuT by using an OR operation

11.1.5

Flow bundles with alternative routes


To display all paths in the flow bundles that do not traverse the selected network objects, show
the alternative routes. Then only those OD relations are taken into account that use the
selected network objects. If 60 % of the paths of an OD pair traverse the link s selected for the
flow bundle, then the alternative routes make up the remaining 40% of the paths of this relation.
These are the OD pair paths that do not traverse the selected link s. In the example in
illustration 231, two links of a bypass (in both line directions) are highlighted for the flow bundle.
The links of each direction are combined through an AND THEN operation. The two AND
THEN operations for the two line directions are combined via an OR operation. So,
independent of the direction, all paths are shown that traverse this link section.

PTV AG

711

Chapter 11: Interactive analyses

Illustration 231: Link flow bundle with AND THEN operation and OR operation

In illustration 232, a flow bundle of alternative routes is displayed for the same flow bundle
criteria as in illustration 231. For all OD pairs for which paths were found in the origin flow
bundle, the paths are listed that do not traverse the link section selected. 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.

712

PTV AG

Chapter 11.2: Isochrones

Illustration 232: Link flow bundle with alternative routes

11.2

Isochrones
Based on one or several selected network objects, isochrones visualize the accessibility of all
other network objects.
The accessibility can be classified in intervals that are highlighted in different colors in the
Network editor. You can, for instance, highlight all towns in the same color that can be
accessed from a specific node within a certain time.
In practice, isochrones are used to analyze the catchment area of stops. In illustration 233, all
stop areas in the urban area were highlighted and then an isochrone calculation was
performed. You can see, that especially potential PuT passengers from the eastern part of the
city (highlighted in dark red) need more than 8 min to the next stop.

PTV AG

713

Chapter 11: Interactive analyses

Illustration 233: Isochrones to display the accessibility of stop areas

The illustration 234 illustrates the effectiveness of isochrones in a simple example. In this
example, isochrones were drawn based on node 20. The travel time in the loaded network
(tCur) was used as the path-choice criterion. The links were labeled with these times. The link
segments were highlighted in different colors depending on their accessibility (here depending
on tCur) (see User Manual, Chpt. 12.3.7, page 1415). If you e.g. travel from node 20 via node
11 to node 41, the in-vehicle time is 29min 35s. Accordingly, the last link section before node
41 is highlighted in dark red, as from here your journey is longer than 26min.

714

PTV AG

Chapter 11.2: Isochrones

Illustration 234: Functional principle of isochrones illustrated in a simple example

If several network objects are selected for 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 e.g. 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 is highlighted accordingly.
Note: The accessibility of network objects can be calculated and displayed simultaneously for
both PuT and PrT.

11.2.1

PrT isochrones
The accessibility of network objects is determined via a shortest path search. Thereby the
following attributes are used as search criteria:

tCur (travel time in loaded network)


t0 (travel time in unloaded network)
Distance
Impedance
AddValues 1 to 3

Note: When selecting the route choice criterion, note that t0, tCur and Impedance
correspond to each other as long as no assignment has been calculated.
You can use nodes, main nodes and zones (or a combination of them) as reference points of
PrT isochrones.

PTV AG

715

Chapter 11: Interactive analyses

The results of PrT isochrone calculation are listed under the attribute Isochrones time PrT of
nodes, main nodes and zones. The minimum run time is listed for each network object.
The following options are available for displaying PrT isochrones graphically in the Network
editor:

Display of the accessibility of link sections


2D drawing
Classified display of nodes, main nodes and zones by Isochrones Time PrT

Accessibility of link sections


This display option shows individual link sections in the color of the accessibility interval they
belong to. The illustration 235 shows the accessibility of link sections from marked node 7357.
Dark red colored link sections can only be reached in more than 10min.

Illustration 235: Accessibility of link sections from node 7357

Classified display of network objects


Like all other attributes, the result of PrT isochrones can be used as a basis for classified
display of nodes and zones.
This means that nodes and zones are highlighted in color, depending on their Isochrones
Time PrT. In illustration 236, zones were classified according to the Isochrones Time PrT.

716

PTV AG

Chapter 11.2: Isochrones

Illustration 236: Classification of zones according to Isochrones time PrT

11.2.2

PuT isochrones
PuT isochrones are used to analyze the accessibility of nodes, stops, stop areas, stop points
and zones within a specified time interval. Accessibility is determined based on a timetablebased connection search. The search can be based on a departure or an arrival time interval.
In the first case, you determine all connections leaving from the network object selected within
a certain time period, including an additional time span. This time span is entered after you
have selected the departure period and refers to the time within which the connection must
reach the destination.
In the second case, you analyze all connections that arrive at the network object selected
within a certain time period and you enter a lead time. This is the time span directly before the
arrival period specified and during which the connections must leave their starting point.
You can use nodes, stop areas and zones (or a combination of them) as reference points of
PuT isochrones.
You can find the results of PuT isochrone calculation in the attributes Isochrones time PuT
and Number of transfers PuT for nodes, stops, stop areas, stop points and zones. For each
network object, the minimum journey time and minimum number of required transfers is listed.
Please note that both values might appear in different connections, i.e. there is not necessarily
one connection with both the minimum journey time and the minimum number of transfers.
The results depend on the time intervals specified. You can influence the calculation (except
for the time reference), by limiting the search to active vehicle journey sections or by specifying
a maximum number of transfers.
The following options are available for displaying PuT isochrones graphically in the Network
editor:

PTV AG

717

Chapter 11: Interactive analyses

2D drawing
The attributes Isochrones time PuT and Isochrones number of transfers PuT can be
used in 2D to classify the accessibility intervals.
Classified representation of nodes, zones, stops, stop areas and stop points
The attributes Isochrones time PuT and Isochrones number of transfers PuT can be
used for a classified representation of one or several network object types.

Isochrone display in 2D
For 2D display, the network background is highlighted in color depending on the individual
accessibility intervals.
In illustration 237, this type of representation is used to visualize the attribute Isochrones time
PuT, i.e. the time required to access stop areas. The main train station is highlighted, i.e. the
isochrones show the PuT journey time starting from the main train station.

Illustration 237: 2D display of the accessibility of stop areas from the main station

Classified display of network objects


Just like all other attributes, the results of PuT isochrones can be used for a classified
representation of nodes, zones, stops, stop areas or stop points:

718

PTV AG

Chapter 11.2: Isochrones

Isochrones time PuT


The illustration 238 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.

Illustration 238: Classified display of stops on the basis of the isochrone time PuT

PTV AG

Isochrones number of transfers PuT


In illustration 239 the Isochrones number of transfers PuT was selected as a classification
criterion. It is then clearly shown which stops can be reached from the main train station
with no transfer, one transfer or more than one transfer.

719

Chapter 11: Interactive analyses

Illustration 239: 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 a single network.
This is how you can compare the accessibility in PrT and PuT. In our example in
illustration 240, the stops are classified and displayed according to the Isochrones Time PuT.
Stop area 106,062,191 was selected for isochrone calculation. For PrT, the link sections are
classified based on isochrone time PrT. Node 106,062,191 was highlighted as a reference
point for the PrT isochrone and is located at the corresponding stop area.
If you now compare accessibility starting from the highlighted node or stop area to the bus
station (stop area 106062529), you can see whether it is quicker to use a car or the bus. Based
on this comparison, you can derive measures, e.g. to increase the attractiveness of PuT.
The illustration 240 graphically shows that the bus station can be reached via PuT
(106,062,529) in <= 6min from starting point (106,062,191). A comparison with PrT (colored
link sections) shows that the same start-destination relation can be covered in less than 3
minutes.

720

PTV AG

Chapter 11.2: Isochrones

Illustration 240: Comparison of accessibility in PrT and PuT in a graphical view

The exact figures are provided in the list view (see illustration 241). The exact Isochrones
Time PrT is 2min 50s, the Isochrones Time PuT is 5min 25s.

Illustration 241: Comparison of accessibility in PrT and PuT in a list view

PTV AG

721

Chapter 11: Interactive analyses

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 242). 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 242: 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.

722

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 timetable-based (PuT tab) or transport systembased (PuT TSys tab).
If a timetable-based search is performed, the connection with a minimum search impedance
is output as the shortest path. Thereby search impedance is 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 you consider a shorter journey time or less transfers 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. A basic network may include the following three options:

All road and rail links of the link network


Only those links traversed by PuT lines
Only those links traversed by active PuT lines

A graph is created from the links of this basic network. If 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. However, it is possible 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 performed
for an area between two zones or two nodes.

PTV AG

723

Chapter 11: Interactive analyses

724

PTV AG

12

Tabular and graphical 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. You can e.g. show the link
volumes calculated in an assignment procedure in table or a list, or graphically as link bars in
the Network editor, as depicted in illustration 243. 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 1369).

Illustration 243: Graphical and tabular display of link volumes

PTV AG

725

Chapter 12: Tabular and graphical display

Subjects

12.1

Lists
Bars
Categorized display with attribute values
Labeling with tables
Labeling with charts
Turn volumes
Desire lines
Stop catchment areas
PuT transfer relations
PuT connections and transfer flows
Lane allocation
2D display
Schematic line diagram
Signal time-space diagram
Column charts
Evaluations in the timetable editor

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
To perform attribute-classified analyses on the properties of network objects

The list columns contain freely selectable attributes, the rows contain different objects. There
are two types of lists, specific lists for each network object type and evaluation lists.

12.1.1

List display and entry options


Lists are mainly used to display the properties of network objects and other network data in a
table. You can specify the number of attributes displayed, the sequence of the columns and the
display format (e.g. decimal places, alignment) for each column. The choice of attributes
together with the column format are called the list layout (see User Manual, Chpt. 12.1,
page 1369). You can save the list layout to files to use it again later. This allows you to open
views of certain network aspects or to prepare for specific tasks.

726

PTV AG

Chapter 12.1: Lists

Using lists, you can access both the direct and indirect attributes of network objects (see User
Manual, Chpt. 2.2, page 146). Indirect attributes are attributes of other network objects, e.g. in
a zones list, you can view the number of origin connectors. You can sort nearly all lists
(exception: path lists) by any column.
The network object data is not only readable, you can also change it directly in the list view. To
do so, simply enter a new value. You can change any editable attributes. To have more
options, activate the Extended input options (see User Manual, Chpt. 12.1.3, page 1373) for
attributes whose specification is limited. You can then change attributes, such as TSysSet, in
a separate window. For attributes including an enumeration type, a list box of options is
displayed in clear text format.
The list allows you to make changes efficiently to several objects and/or attributes at the same
time. To do so, simply highlight the cells you want to change and enter a new value. The new
value is then adopted for all highlighted cells. When making your changes, you cannot only
enter constant values (e.g. "2"), but also simple calculation procedures. If, for instance, you
want to double the length of all links, in the "Links" list, highlight all the cells of the "Length"
column. Enter "=*2" and Visum multiplies each cell value by 2. This option is also available via
the context menu (Arithmetic operations on marked section). When using lists, you can
also use the Windows Clipboard for data exchange, i.e. the Copy and Paste commands for
data exchange with a Microsoft Excel file. To exchange larger amounts of data, you can export
the list content into databases or ASCII-based Visum attribute files (*.att).
Thereby each row in the list represents a network object. Commands for network objects are
also available in the list context menu. To change attributes, you can also open the Change
network object dialog box. The dialog also allows you to delete objects and provides special
functions as the display of column diagrams. If you highlight the cells of several rows, all
changes made using the context menu or the Network editor, will apply to all highlighted
objects. Another option is to open the Multi-edit dialog for the respective network object, which
e.g. allows you to assign attribute values via formulas. Moreover, it provides all the special
Multi-edit functions.
You can synchronize lists of network objects with the Network editor, if they have an own mode
in the Network editor (see User Manual, Chpt. 12.1.9, page 1386). Highlighting objects in the
list then also highlights the same objects in the Network editor window. You can specify to keep
the current view, to show the highlighted network object or to auto zoom into the highlighted
area. Highlighting objects in the network will also highlight the same objects in the list.
Synchronization further allows you to easily perform analyses, e.g. to search for the ten links
with the highest volume, simply show the respective volume attribute in the link list. Then sort
the list by this attribute in descending order and highlight the first ten rows. If you have
activated synchronization, you can then see the respective objects in the Network editor
window.
The synchronization option is also available for some other lists. However, in this case,
synchronization only works in one direction. Highlighting objects in the list will highlight the
same objects in the network, but this does not work vice versa, as other object types cannot be
highlighted in the network. Examples would be item lists (e.g. line routes), paths (PrT paths,
PuT paths) and line blocks. In these lists, you can highlight a row and the geographical course
of the respective object is then also highlighted in the network.
You can aggregate the display of network objects in lists. To do so, select an attribute by which
you want to group the objects. Network objects with the same attribute value are then grouped
in a row. Then an aggregation function is applied to the attribute values of the grouped network
PTV AG

727

Chapter 12: Tabular and graphical display

objects and its value is displayed. Typical aggregation functions are sums, minimum,
maximum, average and weighted mean. You can also use comparison, concatenate,
frequency of occurrence, and distinct occurrence. The frequency of occurrence indicates how
often a value occurs in the data of an aggregated row. The aggregate function distinct
occurrence only lists all occurring values. You can also group network objects by several
attributes at the same time. An example would be an analysis of transferring passengers by
transport systems: In the passenger transfer list, you could show the transport system code of
the from-time profile item and the to-time profile item as indirect attributes. Then you could
group the data by these two columns. As aggregation function for the volume attributes, you
would choose sum. The result is displayed in a from-transport system row and a to-transport
system row. If have not limited your selection to a stop, you can also group the objects by stop
numbers to receive a network-wide overview of the passengers transferring between transport
systems. To copy such a view to a spreadsheet program, highlight all cells. In the same way,
you can perform similar analyses and validity checks or e.g. use the links list to calculate the
average volume of specific links.

12.1.2

Specific network object lists


Specific lists are provided for all network object types (see "Example of a link list" on
page 728). 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 of a link list" on
page 728). Some of these lists have special features that are explained below.

Illustration 244: Example of a link list

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 646). The sublists Basis and
PuT detail are available for territories.

728

PTV AG

Chapter 12.1: Lists

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.
Hint
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.

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 646).
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.

Table 276: Territory lists

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

Note: The matrix values can also be edited in this list, so that you do not have to switch to the
matrix editor.

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.

PTV AG

729

Chapter 12: Tabular and graphical display

Stop points
The list exports the vehicle journeys and attributes of any stop point selected by the
arrivals/departures user such as, Arrival and Departure. As an option, you can also filter according to
time profiles at the selected stop point.
Transfers and stop For each stop, the list contains the transfer walk times and the passenger transfers
area walk times in per transport system between the stop areas of the stop. Use the list for example, if
stop
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.
Time profiles:
Transition walk
times

For each stop, the list contains the transfer times between the time profiles of the
stop.

Transport systems: For each stop, the list contains the transfer times between the transport systems of
Transition walk
the stop.
times

Table 277: Stop 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 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.31.3.3, page 467)

Vehicle journey items

All profile points of the time profile which are traversed by the vehicle journey
selected by the user

System route items

All nodes and stop points which lie on the system route

Table 278: Item lists

In items lists, you can switch between the section view and the classical view. The classical
view displays the sequence of fixed points like stop points, route points or profile points, while
the section view focuses on the items between these points (see User Manual, Chpt. 12.1.6.2,
page 1381).

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.
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 279: Line lists

Line block lists


To display and edit input and output attributes of line blocking, the lists line block versions, line
blocks and line block items are available.

730

PTV AG

Chapter 12.1: Lists

PuT line block


versions

Shows the line block versions contained in the model.

Line blocks

The list shows the line blocks of all line block versions. As an option, only the line
blocks of a line block version selected by the user can be displayed.

Line block items

The individual elements of all line blocks are contained in this list. The list shows the
parts which make up a line block and in which order these are traversed (vehicle
journeys, empty trips, stand times, but also user-defined line block item types). As
an option, only the items of a line block version selected by the user can be
displayed.

Table 280: Line block lists

12.1.3

Matrix list
The matrix list shows an overview of all matrices.

12.1.4

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 245: 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.10, page 1386).
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 an origin zone to a destination
zone.

PrT path sets

Displays any existing PrT path sets.

Table 281: Evaluation lists for paths

PTV AG

731

Chapter 12: Tabular and graphical display

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 437), for PrT via the
procedure Calculate skim matrix (see "PrT skims" on page 290).

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.

PuT path legs

Lists all path legs (see "Network model" on page 29) 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.

Table 281: Evaluation lists for paths

Evaluation lists for transfers


There are three different transfer lists. These lists allow a display of the transfers per stop or
per time profile/transport system and the transfers and stop area walk times within a stop (see
User Manual, Chpt. 12.1, page 1369).
Note: The lists do not contain any entries if no PuT assignment was calculated beforehand.

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.
Note: A previously calculated assignment is not required.

Statistical evaluation lists


Statistics - Network
information

The list provides statistical information on the current network.


Number in 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
Note
The list further allows you to access attributes of the Network object, e.g.
user-defined attributes.

Table 282: Statistical evaluation lists

732

PTV AG

Chapter 12.2: Bars

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 307).
Notes
The convergence criteria are automatically calculated for the PrT
assignment procedures Equilibrium, Equilibrium_Lohse and Stochastic
assignment.
The list further allows you to access attributes of the Network object, e.g.
user-defined attributes.

Statistics - Goodness of
PrT assignment with ICA

Output of convergence criteria as indicators of the PrT assignment quality


for assignments with ICA
Note
The list further allows you to access attributes of the Network object, e.g.
user-defined attributes.

Statistics - Assignment
analysis

Output of the statistical evaluation of the assignment analysis for PrT or PuT
(see "Assignment analysis PrT" on page 426 and "Assignment analysis
PuT" on page 506)

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 450).

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 657)
Note
The list further allows you to access attributes of the Network object, e.g.
user-defined attributes.

Table 282: Statistical evaluation lists

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.5, page 1428). The link
volume from a PrT assignment can thus for example be visualized, like in illustration 246, by
scaling the link bar with the attribute Volume [Veh] PrT.

PTV AG

733

Chapter 12: Tabular and graphical display

Illustration 246: Link bars with PrT volume

Connector bars can also be drawn. In illustration 247 the attribute Volume [Veh] PrT is
displayed on the connectors.

734

PTV AG

Chapter 12.2: Bars

Illustration 247: 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 248.

PTV AG

735

Chapter 12: Tabular and graphical display

Illustration 248: 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.12, page 1466). This makes it
possible to draw links differently in dependency of their link type, for example. In
illustration 249, illustration 250 and illustration 251 link and zone categorizations are
illustrated.

736

PTV AG

Chapter 12.3: Categorized display with attribute values

Illustration 249: Categorized link display according to link category

PTV AG

737

Chapter 12: Tabular and graphical display

Illustration 250: Categorized link display according to saturation PrT

738

PTV AG

Chapter 12.3: Categorized display with attribute values

Illustration 251: Zone categorization according to origin traffic

Bars (see "Bars" on page 733) can also be displayed in categories. In dependency of attribute
Saturation PrT, the link bar is colored red, green or yellow in illustration 252.

PTV AG

739

Chapter 12: Tabular and graphical display

Illustration 252: 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 1400). 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 253).

740

PTV AG

Chapter 12.5: Labeling with charts

Illustration 253: Table display of boarding passengers, transfers and alighting passengers at stops

12.5

Labeling with charts


In the network editor, the network objects can be labeled with freely configurable charts (see
User Manual, Chpt. 12.11.2, page 1461). Bar and pie charts are available. For zones you can
display the number of inhabitants and jobs in a column chart for example (illustration 254).

PTV AG

741

Chapter 12: Tabular and graphical display

Illustration 254: Number of residents and workplaces per zone

You can also display the results of the mode choice (see "Mode choice" on page 130) the
distribution of travel demand to the individual transport modes for each zone in a pie chart
(illustration 255).

742

PTV AG

Chapter 12.6: Turn volumes

Illustration 255: 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 29) at individual
nodes (see User Manual, Chpt. 12.14, page 1486). 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 256).
The turn attributes can also be displayed in a turn list (see "Lists" on page 726).
Tip: In the junction editor, you can also display turn volumes (see User Manual, Chpt.
2.40.18, page 637).

PTV AG

743

Chapter 12: Tabular and graphical display

Illustration 256: 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)

For each OD pair you can draw both a desire line link as well as one or more desire line bars
for a proportional display of the values (see User Manual, Chpt. 12.13, page 1481).
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 257 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.

744

PTV AG

Chapter 12.7: Desire lines

Illustration 257: Desire line with bars scaled at the demand between zones

The desire line is drawn on the linear distance between the zones. If you are interested in the
exact course of the paths between origin and destination zones, use the Shortest Path
Search (see User Manual, Chpt. 11.3, page 1360).
Combined with the OD pair filter (see User Manual, Chpt. 2.7.6, page 210) 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
(see User Manual, Chpt. 12.2, page 1400).
Furthermore, the desire line can also be drawn classified. As shown in illustration 258, you can
highlight OD pairs with a high traffic demand with colors, for example.

PTV AG

745

Chapter 12: Tabular and graphical display

Illustration 258: 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 259. 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.

746

PTV AG

Chapter 12.8: Stop catchment areas

Illustration 259: Stop catchment areas with a large radius of 400m

Stop catchment areas can also be drawn classified. In illustration 260 catchment areas with a
radius of 300m are drawn around the stops. The circles of stops with more than 1,000
departures per analysis period are red, stops with less than 500 departures are orange, and
stops with less than 100 departures are displayed in 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.

PTV AG

747

Chapter 12: Tabular and graphical display

Illustration 260: Stop catchment areas classified according to the number of departures

12.9

PuT transfer relations


The graphics layer Transfer relations allows a display of transfer relations between (active)
stop areas of the (active) stops as volume bars in the network. This view is required in PuT
networks in which the stop hierarchy is used for a realistic modeling of transfers. For each pair
of stop areas you can draw both a transfer link (linear distance between the stop areas) as well
as one or more bars for a proportional display of the values. Use the stop area filter or the
classified display of transfer relations (see User Manual, Chpt. 12.8, page 1449) to limit the
display to particular transfer relations. In addition to transfers, other attributes like, for example,
the different walk times can be displayed graphically.

748

PTV AG

Chapter 12.10: PuT connections and transfer flows

Illustration 261: Transfer relations between stop areas of a stop

12.10

PuT connections and transfer flows


The clock-face transfers view displays connections on the supply side and volumes and
transfer flows on the demand side.
The temporal distribution over the clock-face is defined by a basic cycle. Around the outer edge
of the clock arriving and departing vehicle journeys are shown at the minute they pass the stop.
Within time tolerances, vehicle journeys of the same line and direction can be aggregated to
service groups, separately for arrival and departure. Accordingly, incoming and outgoing
volumes as well as transfer flows within the stop can be displayed on this aggregation level.
For matching connections, the transfer times inclusive of the walk times defined at the stop
need to be taken into account. Transfer times and minimum walk times can be displayed in the
shape of circular arcs for pairs of marked service groups.

PTV AG

749

Chapter 12: Tabular and graphical display

Illustration 262: Transfers display of regular services

The assessment of connections is an important task for a planner. The view allows a detailed
evaluation of connections and consistent connections, in particular in combination with
differentiated demand flows. You can easily test and analyze the impact of several service
variants on the demand flows at important transfer points.
The view of the clock-face primarily allows an analysis of transfer flows according to temporal
aspects. Respective evaluations can be supplemented by the graphic display of the spatial
transfer relations between stop areas in the network.

12.11

Lane allocation
To visualize the node topology in the network editor (see "Junction modeling" on page 78) 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. The illustration 263 shows an example of a node with
four legs.

750

PTV AG

Chapter 12.11: Lane allocation

Illustration 263: 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. The illustration 264 demonstrates this with an example of a roundabout.

Illustration 264: Classified lane allocation according to the node volume

PTV AG

751

Chapter 12: Tabular and graphical display

12.12

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 twodimensional 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 P1 with co-ordinates (x,y) = (0,0) has AddVal1 = 100. Point P = (300, 400) has a distance
2

of 500 = 400 + 300 to P1. 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 P1-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 Pi 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 265) of the selected class.

752

PTV AG

Chapter 12.12: 2D display

Illustration 265: 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 1349) 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 v = s- is still used by Visum. For calculation of t values, speed is
t
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 t = -s- produces a value in [seconds], which is, depending on the
v
attributes data type, interpreted as 1 unit. See example above: the resulting 360 [s] are added
to the AddVal data.

PTV AG

753

Chapter 12: Tabular and graphical display

12.13

Schematic line diagram


The schematic line diagram visualizes PuT supply in the form of a schematic network display
similar to the flow bundles in the network. The tool is also known as Timetable network graph
(used in earlier versions of Visum). In this display selected stops of the network, the so-called
transfer nodes, are symbolized by squares which are connected to one or more edges each.
They each represent a subset of the vehicle journeys of the PuT supply with specific properties
between the transfer nodes. The display can be supplemented by bars, transfer flows, labels
and a legend.
In the planning process, this display format serves a better understanding of the current supply
concept and the optimization and manual planning of timetables and connections, especially in
combination with other views (synchronization of the marked stops), for example the clock-face
transfers view (see "PuT connections and transfer flows" on page 749). In addition, the finished
graphics can be used to communicate planning results to other planners, decision makers or
customers. It can also be updated when changes occur in the timetable supply.

12.13.1

Defining and editing a schematic line diagram


To create a schematic line diagram, you first need to add the relevant transfer nodes to the
graphics, individually (see User Manual, Chpt. 12.16.3.1, page 1502) or bundled by a filter (see
User Manual, Chpt. 12.16.3.2, page 1503). Visum automatically positions the squares that
symbolize a transfer node each based on the geographical location of the nodes and avoids a
graphical overlap. You can edit the position of the transfer nodes to achieve the desired layout
(see User Manual, Chpt. 12.16.6.1, page 1512). This does not change the geographical
location of the stops in the network. Stops that are added later will be positioned automatically
by Visum even if the display is stretched or compressed.
To add edge courses to the view, you have to select the relevant vehicle journeys individually
or by choosing time slots, lines, directions, line routes or time profiles (see User Manual, Chpt.
12.16.4, page 1503). An edge course in the schematic line diagram always represents a set of
vehicle journeys. Depending on the aggregation function and the connection of edges (see
User Manual, Chpt. 12.16.8, page 1517), Visum generates one or more edge courses between
the transfer nodes. These are inserted automatically, preferably without any overlap and
arranged in a clearly visible manner. The size of each transfer node is adjusted depending on
the number of attached edge courses. You can manually edit the courses as well as the
positions where the edge courses touch the transfer nodes. Edge courses can have any
number of intermediate points between which they are always arranged rectangularly or
diagonally. A help grid is used for the positioning of the transfer nodes and the edge courses,
which can be displayed, if needed.
Besides the manual editing of the layout, you can optimize the positions of the transfer nodes
and the edge courses later with an automatic algorithm.

12.13.2

Display of supply in the schematic line diagram


The edge courses displayed in the schematic line diagram represent subsets of the vehicle
journeys, more precisely the respective vehicle journey items, operating between the transfer
nodes. The total set of vehicle journey items displayed in the schematic line diagram is based
on the selected transfer nodes and vehicle journeys. This set is displayed through one or more

754

PTV AG

Chapter 12.13: Schematic line diagram

edge courses between two transfer nodes, the number of edges resulting from the relevant
start and end points of the edges of one of the following objects:

all stops where boarding or alighting is permissible


all stops with profile points
all stops with route points
all stops of the line route
line route items with a specific attribute value

This allows you to realize different views of the timetable (passenger view, operation level).
The number of edges between the two transfer nodes results from vehicle journey aggregation
performed on a chosen aggregation level (see User Manual, Chpt. 12.16.8, page 1517).
Besides the 'typical' aggregation of the vehicle journeys based on the service pattern or lines
between the transfer nodes, further aggregation levels can be chosen:

Service trip pattern number (=service pattern)


Line directed / undirected
Main line directed / undirected
Line route
Vehicle journey (no aggregation)
Time profile
Transport system directed / undirected
Operator directed / undirected

Some aggregation levels distinguish between directed and undirected. This way you can
control if one edge course each will be created between the transfer nodes or only one
common edge course for both "running directions". In the case of the other aggregation levels
which relate to vehicle journey-based attributes, an undirected display does not make sense;
therefore only directed edge courses will be created.
For the aggregation by service trip pattern number, the respective input attribute will be used.
It can either be determined manually, via the Calculate service trip patterns (see User
Manual, Chpt. 6.5, page 1152) procedure or the respective Multi-edit functionality for vehicle
journeys. There you will find the description of the algorithms for the calculation of the service
trip patterns.
For edge courses, you can specify the standard graphic parameters for line objects. As a
special feature, you can classify edge courses on two classification levels, for example to
combine a display of the service frequency with the standard colors for specific lines. For the
illustration of the service frequency in particular, several new line styles featuring up to four
parallel lines can be selected (see User Manual, Chpt. 12.16.5, page 1504).
For coupled vehicle journey sections, you can display branches in the schematic line diagram.
Furthermore, you can bundle edge courses manually. This way you can display supplies as
such, where a headway of an hour can be achieved by an alternate service of a main section
instead of lines operating with a headway of two hours with deviating destinations.
The edge courses can be labeled with attribute values at the start transfer node and end
transfer node each and at the center of the course. For the transfer nodes, up to three attribute
values can be used for the label within or at a chosen position outside of the rectangle.
For the classification and labels of the edge courses, some attributes aggregated from the data
of the underlying vehicle journeys are available:

PTV AG

755

Chapter 12: Tabular and graphical display

Headway
Departure and arrival times
Number of stopovers
Run times
Volumes

In addition, relations to vehicle journey items and to the opposite direction are available. They
provide access to further aspects of the data model.

12.13.3

Display of demand and transfer flows in the schematic line diagram


On the edge courses you can display any attribute values of the underlying vehicle journeys,
for example volumes. For the formatting of bars, especially for a classified display, the
standard graphic parameters are provided (see User Manual, Chpt. 12.16.5, page 1504).
Unlike for link bars, the attribute value allocated to an edge is not constant over the entire
course, because an edge symbolizes a set of vehicle journeys between any selected transfer
nodes, so that the volume, for example, may differ at the hidden stopovers. Bars can thus be
divided at the centered label and show the attribute values that each apply to the start transfer
node and the end transfer node on the two sections.
To visualize transfer flows you can display bars between the incoming and outgoing edge
courses within the transfer nodes. You can specify the bar display with the standard
parameters.

12.13.4

Saving layout information and transferring layouts to variants


On the one hand, the arrangement of the elements in the schematic line diagram is based on
the selection of transfer nodes and vehicle journeys. On the other hand, it is optimized and
adjusted to your needs by manual modifications. In many cases, a suitable arrangement shall
be used for other variants and timetable updates. If they were linked to the data structures in
the data model, manual modifications would be lost as soon as an edge course disappeared
from the schematic line diagram, e.g. due to the selection of a different aggregation level, a
modification of the vehicle journey selection, or changes to or even replacements of timetable
data (e.g. due to data import for a new timetable period). To retain a manually edited layout of
the schematic line diagram despite such modifications and transfer the layout to other supply
variants in other version files, the following mechanisms are provided. Besides automatically
saving parameters in the version file, you can separately save all parameters to files and reload
them, which allows you to easily transfer the layout and graphic parameters to other version
files. The settings are saved in two kinds of files. The graphic parameters file contains all purely
graphic settings regarding colors, bars and so on. The layout file contains the settings
regarding selected transfer nodes and vehicle journeys and their positions and courses as well
as the information on the allocation of vehicle journeys to edge courses. In the schematic line
diagram, the allocation of vehicle journeys to edge courses is not controlled by the actual key
attribute (i.e. the vehicle journey number) but, depending on the selected aggregation level, via
a set of identifying attributes. In the layout parameters window (see User Manual, Chpt.
12.16.8, page 1517), these attributes are listed in the field Identification attribute for unused
edge courses. When editing the timetable data or the layout parameters (for example the
vehicle journey selection), the vehicle journeys are reallocated to the edge courses based on
these attributes, new edge courses are created, if necessary, existing ones are hidden and the
graphic display is adjusted. Even for hidden edge courses the layout parameters will not be

756

PTV AG

Chapter 12.14: Signal time-space diagram

lost, i.e. Visum "remembers" that there used to be an edge course for line A between transfer
node 123 and 987 with a manually adjusted course, even if the edge is not displayed any more.
This information is used again when requesting an edge course with the same key once more.
You can, however, explicitly empty this "memory" of the schematic line diagram.
The dynamic allocation of vehicle journeys to edge courses and the preservation of the layout
information on hidden edge courses allows you to retain a display despite of changes to or a
complete exchange of the timetable data (with deviating vehicle journey numbers) and use it
on other supply variants. In particular, this mechanism allows the use of the schematic line
diagram together with the scenario management, when, for example, creating a line diagram
with the desired layout in the base version which will then be automatically adjusted to the data
of the scenario when opening scenario results.

12.14

Signal time-space diagram


With the signal time-space diagram (see User Manual, Chpt. 12.17, page 1520), you can
display the signal times of signal controls along a path (see "Paths" on page 52) in a timedistance diagram and manually adjust and optimize the offset between the signal controls.
Optionally, green bands can also be displayed for a second path in opposite direction. The
green bands start at the green times of the upstream signal controls and extend in driving
direction to the next signal control. The gradient is determined on the basis of the travel time
that is calculated according to the parameters set for the signal offset optimization (see User
Manual, Chpt. 5.4.2, page 1004). You can choose between two different display modes for the
signal space-time diagram. In the "Flowing off" mode, the green bands are drawn as
parallelograms whose width corresponds to the entire green time of the upstream signal
controls. In the "Arterial bands" mode, the green band with the maximum width is determined
which leads through the green stages of all signal controls of the signal time-space diagram
("progressive signal system"). If such a green band cannot be found, no green band will be
drawn.

PTV AG

757

Chapter 12: Tabular and graphical display

Illustration 266: Signal time-space diagram in mode "Flowing off"

Illustration 267: Signal time-space diagram in mode "Arterial bands"

758

PTV AG

Chapter 12.15: Column charts

The offset of the signal controls can be edited directly in the diagram in order to synchronize
the green bands.
A user-defined PrT path which shall be used for the opposite direction, must have at least two
nodes in common with the path of the first direction and all intermediate nodes must be
traversed in reverse order. This requirement permits the use of two separate paths for the
display and thus, for example, the consideration of lanes divided by direction.

12.15

Column charts
You can create column charts with values of direct and indirect attributes (see "Attributes" on
page 94) from the network editor, for individual network objects (see User Manual, Chpt. 12.14,
page 757). 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 84) 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. The illustration 268 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.

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 269, 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.

Illustration 268: Column charts for time intervals

PTV AG

759

Chapter 12: Tabular and graphical display

Illustration 269: Column chart for relations between network objects

12.16

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.43, page 658).
The timetable editor also offers a block view for line blocks (see "Displaying line blocks in the
block view" on page 1183).

Tabular timetable
In the standard view, the tabular timetable is presented as in illustration 270.

760

PTV AG

Chapter 12.16: Evaluations in the timetable editor

Illustration 270: Tabular timetable in the standard view

In the regular service mode (see User Manual, Chpt. 2.43.4, page 663) all vehicle journeys are
displayed as regular services with the additional attributes Headway start, Headway end,
Headway time and Number of vehicle journeys (illustration 271).

PTV AG

761

Chapter 12: Tabular and graphical display

Illustration 271: 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 1400). In the following example, the table background is classified by revenues
(illustration 272).

762

PTV AG

Chapter 12.16: Evaluations in the timetable editor

Illustration 272: Table background classified by revenue

Graphical timetable
Vehicle journeys and vehicle journey sections are displayed graphically in the graphical
timetable. In illustration 273, the stroke display is classified according to lines (see User
Manual, Chpt. 12.2, page 1400), to distinguish vehicle journeys of different lines by using
different colors.

PTV AG

763

Chapter 12: Tabular and graphical display

Illustration 273: Graphical timetable with classified display of vehicle journey line style properties

Item bars, which can be scaled with direct and indirect vehicle journey or vehicle journey
section attributes, can be drawn for vehicle journeys and vehicle journey sections (see User
Manual, Chpt. 12.2, page 1400). In the following example, the Volume of the vehicle journeys
is used as scaling attribute (illustration 274).

764

PTV AG

Chapter 12.16: Evaluations in the timetable editor

Illustration 274: Item bars for vehicle journeys

Item bars can also be classified (see User Manual, Chpt. 12.2, page 1400). In illustration 275
classification is carried out with the vehicle journey volume.

PTV AG

765

Chapter 12: Tabular and graphical display

Illustration 275: Classification of item bars with the vehicle journey volume

Visum offers the possibility of displaying multiple bars with different attributes on vehicle
journeys or vehicle journey sections (see User Manual, Chpt. 12.2, page 1400). The
illustration 276 displays bars for Boarding passengers, Alighting passengers and Through
passengers.

766

PTV AG

Chapter 12.16: Evaluations in the timetable editor

Illustration 276: Display of item bars for boarding passengers, through passengers and alighting
passengers

PTV AG

767

Chapter 12: Tabular and graphical display

768

PTV AG

Literature
Bellei, G.; Gentile, G.; Meschini, L.; Papola, N.: A demand model with departure time choice for withinday 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 Russian). 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 Russian). Shurnal vycisl.
mat. i mat. fiz. 7 (1967), No. 3, pages 620-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 (publisher): Richtlinien fr den Lrmschutz an Straen, Ausgabe 1990
(RLS-90). Federal Ministry of Transport, Building and Urban Affairs, 1990
EMNID-Institut GmbH (publisher): 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, pages 105-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 (publisher): Leitfaden fr
Verkehrsplanungen. Kln : FGSV, 1985. (Road Traffic Resarch Association in Germany), 1985
Forschungsgesellschaft fr Straen- und Verkehrswesen (publisher): Richtlinien fr die Anlage von
Straen, Teil: Wirtschaftlichkeitsuntersuchungen (RAS-W86). Kln : FGSV, 1986 (Road
Traffic Resarch Association in Germany)

PTV AG

769

Forschungsgesellschaft fr Straen- und Verkehrswesen (publisher): Empfehlungen fr


Wirtschaftlichkeitsuntersuchungen an Straen (EWS-97): Aktualisierung der RAS-W86. Kln :
FGSV, 1997. (Road Traffic Resarch Association in Germany)
Furness, K. P.: Trip forecasting. Unpublished presentation. 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 (publisher): 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. In: 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. 353. Montral, Universit de Montral,
Dpartement d'informatique et de recherche oprationelle (IRO), 1980

770

PTV AG

Leutzbach, W.; Haupt, T.; Mott, P.: Ermittlung der Verkehrsnachfrage. In: Forschung Stadtverkehr, Reihe
Auswertungen, Heft A4, 1988. (Determination of Travel Demand)
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, p. 102, 1997 (Calculating
passenger demand flows)
Lohse, D.; Wegener, B.: Abschnitt 3: Verkehrsplanerische Berechnungsverfahren. In: Bauakademie der
DDR (publisher): 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. (publisher): Proceedings of the 11th Symposium on
Control in Transportation Systems - CTS 2006, pages 73-78, Delft, 2006
Nordic Council of Ministers (publisher): 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
Verkehrsangebotsund
Verkehrsnachfragemodellierung. Scientific series of Institut fr Verkehrsplanung und
Straenverkehr of TU Dresden, Vol. 8, 2004 (Transport supply and Traffic demand modelling)

Schmiedel, R.: Bestimmung verhaltensorientierter Personenkreise fr die Verkehrsplanung. Karlsruhe,


Universitt (TH), Fakultt fr Bauingenieur- und Vermessungswesen, Diss., 1984 (Dissertation
on 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. 2. Berlin
: Verlag fr Bauwesen, 1997 (Foundations of Traffic Engineering and Transportation Planning)

PTV AG

771

Sonntag, H. u.a.: Entwicklung eines Wirtschaftsverkehrsmodells. Bundesministerium fr Verkehr. Berlin,


1995 - Forschungsbericht im Auftrag des Bundeministeriums fr Verkehr (Commercial
transport model development)
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

772

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Illustration 4: Network of the version used for version comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Illustration 5: Network with version comparison: The volumes of both versions compared as well their
difference are displayed. "Verscomp" is the name of the version comparison. . . . . . . . . . . . 13
Illustration 6: Network 1 used for merge network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Illustration 7: Network 2 used for merge network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Illustration 8: Merge network of network 1 and network 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Illustration 9: Configuration of the Scenario calculation server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Illustration 10: Connection between transport systems, modes, demand segments and demand matrices . 34
Illustration 11: Example of a TURNSTANDARD table in the network file, which is used to specify
standard values for turn penalties and turn capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Illustration 12: Rank of the link type and its resulting major flows (yellow), flow hierarchy (red) . . . . . . . 42
Illustration 13: Examples for defining transport systems of a link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Illustration 14: Example for the different speeds of two PrT transport systems depending on the volume. . . 44
Illustration 15: Transportation demand between zones illustrated in the transport network and as a
demand matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Illustration 16: Supply of the travel demand via connectors to the network . . . . . . . . . . . . . . . . . . . . . . . 47
Illustration 17: Possibilities for modeling connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Illustration 18: Intersection area with multiple nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Illustration 19: Node and link types of main nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Illustration 20: Main turns open to traffic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Illustration 21: Main turns not open to traffic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Illustration 22: The stop hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Illustration 23: Possibilities of modeling stop points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Illustration 24: The line hierarchy used to model the PuT supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Illustration 25: Example for two line routes of a line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Illustration 26: Example of two time profiles of a line route. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Illustration 27: Lengths in Visum and their coherence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Illustration 28: Assignment of run times in Visum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Illustration 29: Example of the aggregation of line routes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Illustration 30: Examples: Coupling two and three line routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Illustration 31: Calculation example for the calculation of indicators in case of couplings . . . . . . . . . . . . 69
Illustration 32: Reachability analyses for secondary schools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Illustration 33: Allocating POIs to links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Illustration 34: Visualization of the local position of count locations with the date of the count . . . . . . . . 75
Illustration 35: The Congestion Charge in London is an area toll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Illustration 36: Summation and average calculations with screenlines. . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Illustration 37: Calculation of the urban traffic volume with screenlines . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Illustration 38: Time series by percentage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Illustration 39: Time series of matrix numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Illustration 40: The relationship between the different analysis time slots . . . . . . . . . . . . . . . . . . . . . . . . 89
Illustration 41: Assignment not possible because the validity of the demand and the assignment time
interval do not overlap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
PTV AG

773

List of illustrations

Illustration 42: The demand between 6:30 and 7:30 a.m. is assigned. . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Illustration 43: The demand between 6:30 and 7:30 a.m. is assigned. . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Illustration 44: Structural data of zones stored in user-defined attributes . . . . . . . . . . . . . . . . . . . . . . . 102
Illustration 45: Count data stored in user-defined link attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Illustration 46: Generating a subnetwork with stop point matrices regarding path legs and stop point
matrices regarding paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Illustration 47: Positive and negative surfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Illustration 48: Correlations between different demand objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Illustration 49: Integrated 4-step demand model in Visum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Illustration 50: Extended 4-step model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Illustration 51: Modeling through decision tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Illustration 52: Daily time series for origin-destination groups of HW and WH (SrV 1987 Dresden) . . . 136
Illustration 53: EVA1 function in dependence of impedance w . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Illustration 54: EVA2 function in dependence of the parameters a and b . . . . . . . . . . . . . . . . . . . . . . . 157
Illustration 55: Application of tolerance value in Go to procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Illustration 56: Impedance calculation for a PuT connection, for clarity illustrated in the unit [min] . . . . 208
Illustration 57: Example network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Illustration 58: VD function type BPR according to the Traffic Assignment Manual. . . . . . . . . . . . . . . . 220
Illustration 59: VD function type INRETS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Illustration 60: VD function type LOHSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Illustration 61: Capacity analysis process for signalized nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Illustration 62: Method of calculation at two-way stops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Illustration 63: Calculation process for an All-Way stop node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Illustration 64: Calculation process for roundabouts according to HCM 2010 . . . . . . . . . . . . . . . . . . . . 268
Illustration 65: Approaching flows at a four-leg roundabout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Illustration 66: Calculation process for roundabouts according to the TRL/Kimber method . . . . . . . . . 273
Illustration 67: Description of the node geometry for the TRL/Kimber model . . . . . . . . . . . . . . . . . . . . 274
Illustration 68: Example network for signal coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Illustration 69: Green time split at all nodes with succeeding left turns . . . . . . . . . . . . . . . . . . . . . . . . . 283
Illustration 70: A path through the example network passes SCs at nodes 7003, 8003, 8002 and 9002 . . . 284
Illustration 71: Progression quality for approach West at node 8003. . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Illustration 72: Progression quality for approach North at node 8002 . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Illustration 73: Example network for proportional distribution of the traffic demand. . . . . . . . . . . . . . . . 291
Illustration 74: Blocking back model, phase 1: Formation of congestion Iteration steps 1 and 2. . . . . . 299
Illustration 75: Blocking back model, phase 1: Formation of congestion Iteration step 3, route 1 . . . . . 299
Illustration 76: Blocking back model, phase 1: Formation of congestion Iteration step 3, route 2 . . . . . 300
Illustration 77: Blocking back model, phase 1: Formation of congestion Iteration step 4, route 1 . . . . . 300
Illustration 78: Blocking back model, phase 1: Formation of congestion Iteration step 4, route 2 . . . . . 301
Illustration 79: Blocking back model, phase 2, relief of congestion. Initial situation. . . . . . . . . . . . . . . . 302
Illustration 80: Blocking back model, phase 2, relief of congestion. Iterations step 1, route 1. . . . . . . . 302
Illustration 81: Blocking back model, phase 2, relief of congestion. Iteration step 1, route 2. . . . . . . . . 303
Illustration 82: Blocking back model, phase 2, relief of congestion. Iteration step 2, route 1. . . . . . . . . 303
Illustration 83: Blocking back model, phase 2, relief of congestion. Iteration step 2, route 2. . . . . . . . . 304
Illustration 84: Blocking back model, phase 2, relief of congestion. Iteration step 3, route 1. . . . . . . . . 304
Illustration 85: Blocking back model, phase 2, relief of congestion. Iteration step 3, route 2. . . . . . . . . 305
Illustration 86: Integral indicating the overall wait time over the interpolated measured queue lengths 307
Illustration 87: Parameterization of the Kirchhoff distribution model . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Illustration 88: Parameterization of the Logit distribution model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310

774

PTV AG

List of illustrations

Illustration 89: Parameterization of the Box-Cox distribution model . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Illustration 90: Parameterization of the Lohse distribution model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 91: Distribution with variable beta according to the modified Kirchhoff rule
(please refer to Schnabel / Lohse) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 92: Parameterization of the Lohse distribution model with variable Beta . . . . . . . . . . . . . . .
Illustration 93: Procedure of the incremental assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 94: Example network for the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 95: Procedure of the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 96: Procedure of the network balancing for an OD pair in the equilibrium assignment. . . . .
Illustration 97: Linear User Cost Equilibrium between two paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 98: Numerical example of the procedure to obtain the descent direction . . . . . . . . . . . . . . .
Illustration 99: Numerical example of the procedure to obtain the descent direction . . . . . . . . . . . . . . .
Illustration 100: Example for the proportionality with balanced link volumes . . . . . . . . . . . . . . . . . . . . .
Illustration 101: Extended example for the proportionality with balanced link volumes . . . . . . . . . . . . .
Illustration 102: Procedure of the Equilibrium_Lohse assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 103: ICA-based impedance calculation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 104: Procedure of the assignment with ICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 105: Procedure of the stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 106: Discarding routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 107: Example for similarity of routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 108: Volumes and link run times after the first internal iteration step m=1 . . . . . . . . . . . . . .
Illustration 109: Example for area toll: The London Congestion Charging Zone . . . . . . . . . . . . . . . . . .
Illustration 110: Reducing the area toll to the link toll case
(For clarity reasons, turns without toll are not displayed) . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 111: Toll station at highway exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 112: Example of a matrix toll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 113: Shortest path search graph with matrix toll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 114: Time-cost diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 115: Density function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 116: Distribution function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 117: Path Search. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 118: Distribution of the traffic demand onto the routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 119: Equilibrium formation with TRIBUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 120: Attribute selection for the Toll systems list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 121: Attribute selection for the Toll matrices list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 122: The dynamic user equilibrium problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 123: Time slice approach (left side) and time profile approach (right side) to the
Continuous Dynamic Network Loading problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 124: Scheme of the fixed point formulation for the WDDTA with spillback congestion . . . . .
Illustration 125: Recursive expressions of path exit time, entrance time and cost . . . . . . . . . . . . . . . . .
Illustration 126: The adopted parabolic-trapezoidal fundamental diagram, expressing the relation
among vehicular flow, speed and density along a given arc. . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 127: The trapezoidal fundamental diagram suggested for urban links . . . . . . . . . . . . . . . . .
Illustration 128: Scheme of the fixed point formulation for the NPM. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 129: Arc with time-varying capacity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 130: Flow pattern given by the Simplified Theory of Kinematic Waves. . . . . . . . . . . . . . . . .
Illustration 131: Flow pattern given by the Averaged Kinematic Wave model . . . . . . . . . . . . . . . . . . . .
Illustration 132: Determination of the arc hypocritical exit time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 133: Trajectories of a hypercritical kinematic wave and of the intersecting vehicles . . . . . .

PTV AG

311
312
313
314
318
323
328
329
335
339
340
344
345
353
355
363
369
370
371
375
379
380
381
381
382
383
384
385
385
386
387
388
389
390
391
392
394
395
396
397
399
400
401
402
404

775

List of illustrations

Illustration 134: Graphical determination of the time series of the inflow capacity in the case of
triangular fundamental diagram, piecewise constant inflow, and constant exit capacity . . .
Illustration 135: Dynamic version of the Bellman relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 136: 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) . . .
Illustration 137: Example network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 138: Results of WDDTA without and with spillback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 139: Shape of the fundamental diagram based on the link attributes . . . . . . . . . . . . . . . . .
Illustration 140: Parabolic sub-critical branch in the fundamental diagram . . . . . . . . . . . . . . . . . . . . . .
Illustration 141: Signalized intersection in reality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 142: Diagram of the signalized node in Visum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 143: Example of the impedance calculation of a connection . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 144: Example of the network volume along a connection . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 145: Procedure of the dynamic stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 146: Different modeling options for main and subordinated networks . . . . . . . . . . . . . . . . .
Illustration 147: Timetable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 148: Line map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 149: Example network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 150: Example for indicator value calculation for partially traversed links . . . . . . . . . . . . . . .
Illustration 151: Network volume after transport system-based assignment (parameters file TSys1.par). .
Illustration 152: Network volume after transport system-based assignment (parameters file TSys2.par). .
Illustration 153: Example network for choice models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 154: Structure of the choice in scenario 1 (no information) . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 155: Structure of the choice in scenario 2 (local information). . . . . . . . . . . . . . . . . . . . . . . .
Illustration 156: Structure of the choice in scenario 3 (information in the vehicle) . . . . . . . . . . . . . . . . .
Illustration 157: Volume for headway-based assignment, transfer penalty 2 min . . . . . . . . . . . . . . . . .
Illustration 158: Coordination of lines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 159: Network volume for timetable-based assignment (parameter file timetab1.par) . . . . .
Illustration 160: Flow chart of a timetable-based assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 161: Smoothing of the vol/cap ratio in iteration i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 162: Readiness to change dependent on the alternative's departure time . . . . . . . . . . . . .
Illustration 163: Standard questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 164: Processing of PuT passenger surveys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 165: Validity check of the survey path leg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 166: Validity check of the preceding section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 167: Territories in the example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 168: Line 2 traverses several territories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 169: Allocation of vehicles and operators in the line hierarchy. . . . . . . . . . . . . . . . . . . . . . .
Illustration 170: Example line block with pull-out trip, interlining trip and pull-in trip . . . . . . . . . . . . . . .
Illustration 171: Conflict between empty trips and vehicle demand . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 172: Line network of the example with three bus lines (red, blue and yellow) . . . . . . . . . . .
Illustration 173: (Graphical) timetable of the example, color codes as above . . . . . . . . . . . . . . . . . . . .
Illustration 174: Covering the timetable through pure line blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 175: Covering the timetable through blocks without empty trips . . . . . . . . . . . . . . . . . . . . .
Illustration 176: Covering the timetable through line comprehensive blocks with empty trips . . . . . . . .
Illustration 177: Unsymmetrical timetable with trips beyond 24 hours . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 178: Blocking days and vehicle demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 179: Display of a change of the running direction in the course of vehicle journey block
items. The line route makes a U-turn in the station "TFS". . . . . . . . . . . . . . . . . . . . . . . . . .

776

405
407
409
411
412
414
415
416
416
421
421
425
430
433
433
442
450
452
452
467
468
468
469
473
474
491
493
504
505
511
513
515
516
524
526
531
533
535
537
537
539
541
543
545
549
558

PTV AG

List of illustrations

Illustration 180: State model for line blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Illustration 181: Example for partitioning according to vehicle combination and operator . . . . . . . . . . .
Illustration 182: Inserting the nodes and edges for vehicle journey sections . . . . . . . . . . . . . . . . . . . . .
Illustration 183: Inserting the edges for entering the depots and for empty trips between stop points . .
Illustration 184: Inserting the edges for leaving from depots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 185: Example graph after inserting the timeline edges and edge reduction . . . . . . . . . . . . .
Illustration 186: Optimal cost flow in the example graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 187: Example 1 for the decomposition into blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 188: Example 2 for the decomposition into blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 189: Example for block display of a block with 5 blocking days . . . . . . . . . . . . . . . . . . . . . .
Illustration 190: Possibilities of fare modeling in Visum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 191: Example for a distance-based fare with 5 fare stages . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 192: Example for a zone-based fare with three overlapping fare zones and six stops. . . . .
Illustration 193: Example network with two lines and volume data. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 194: Calculation of service kilometers between 8 a.m. and 9 a.m. . . . . . . . . . . . . . . . . . . . .
Illustration 195: Calculation of passenger kilometers between 8:00 a.m. and 9:00 a.m. . . . . . . . . . . . .
Illustration 196: Calculation of passenger kilometers between 8 a.m. and 9 a.m. . . . . . . . . . . . . . . . . .
Illustration 197: Calculation schema for costs and revenues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 198: Calculation of the fare points for path legs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 199: Example network for fixed amount per path leg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 200: Time-distance diagram for a vehicle journey with two vehicle journey sections . . . . . .
Illustration 201: Aggregation along the line hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 202: Aggregation of the service kilometers from the trips onto the line. . . . . . . . . . . . . . . . .
Illustration 203: Interpolation of passage times (run times in minutes). . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 204: Partially traversed links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 205: Influence of couplings on the indicator calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 206: Extended projection of attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 207: Illustration of noise volume as link bars. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 208: Emissions relative to speed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 209: Display of nitrogen monoxide volumes as link bars . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 210: Evaluation period and annuities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 211: Depiction of the results in EWS window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 212: Source and target attribute allocations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 213: Land use from two shape files as background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 214: Examples of overlapping network objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 215: Intersecting three polygon objects with a link buffer . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 216: Intersecting point objects with a polygon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 217: Intersecting point objects with a buffer polygon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 218: Intersecting point object buffers with polygons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 219: Legend with user-defined texts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 220: Visum network display without background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 221: Visum network display with background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 222: The flow bundle as path filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 223: Display of the flow bundle paths in the PuT path leg list . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 224: PuT node flow bundle with additional filter criteria for lines. . . . . . . . . . . . . . . . . . . . . .
Illustration 225: Some of the paths which traverse node 100001 and use line 002 . . . . . . . . . . . . . . . .
Illustration 226: Display of through traffic with a flow bundle of active links . . . . . . . . . . . . . . . . . . . . . .
Illustration 227: Paths which start in zone 102 and end in zones 1, 2 or 5. . . . . . . . . . . . . . . . . . . . . . .
Illustration 228: All paths which traverse a link section in north direction . . . . . . . . . . . . . . . . . . . . . . . .

561
564
565
566
567
568
570
571
572
579
583
587
588
606
617
621
622
623
635
638
643
645
645
646
647
648
649
654
655
656
664
669
674
675
677
684
685
685
685
689
692
692
698
698
700
700
702
707
708

PTV AG

777

List of illustrations

Illustration 229: Through traffic traversing the two links in the sequence specified . . . . . . . . . . . . . . . .
Illustration 230: Combining flow bundles for PrT and PuT by using an OR operation . . . . . . . . . . . . . .
Illustration 231: Link flow bundle with AND THEN operation and OR operation . . . . . . . . . . . . . . . . . .
Illustration 232: Link flow bundle with alternative routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 233: Isochrones to display the accessibility of stop areas . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 234: Functional principle of isochrones illustrated in a simple example . . . . . . . . . . . . . . . .
Illustration 235: Accessibility of link sections from node 7357 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 236: Classification of zones according to Isochrones time PrT . . . . . . . . . . . . . . . . . . . . . .
Illustration 237: 2D display of the accessibility of stop areas from the main station . . . . . . . . . . . . . . .
Illustration 238: Classified display of stops on the basis of the isochrone time PuT . . . . . . . . . . . . . . .
Illustration 239: Classified display of stops on the basis of the isochrone number of transfers . . . . . . .
Illustration 240: Comparison of accessibility in PrT and PuT in a graphical view . . . . . . . . . . . . . . . . .
Illustration 241: Comparison of accessibility in PrT and PuT in a list view . . . . . . . . . . . . . . . . . . . . . .
Illustration 242: Shortest path search between two nodes in PrT . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 243: Graphical and tabular display of link volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 244: Example of a link list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 245: PrT path list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 246: Link bars with PrT volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 247: Connector bars with PrT volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 248: Two link bars with PrT and PuT volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 249: Categorized link display according to link category . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 250: Categorized link display according to saturation PrT . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 251: Zone categorization according to origin traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 252: Link bar display categorized according to saturation PrT. . . . . . . . . . . . . . . . . . . . . . .
Illustration 253: Table display of boarding passengers, transfers and alighting passengers at stops . .
Illustration 254: Number of residents and workplaces per zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 255: Display of the mode selection as pie charts for zones . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 256: Display of turn volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 257: Desire line with bars scaled at the demand between zones. . . . . . . . . . . . . . . . . . . . .
Illustration 258: Desire line with bars classified according to the demand between zones . . . . . . . . . .
Illustration 259: Stop catchment areas with a large radius of 400m . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 260: Stop catchment areas classified according to the number of departures. . . . . . . . . . .
Illustration 261: Transfer relations between stop areas of a stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 262: Transfers display of regular services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 263: Lane allocation in the network display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 264: Classified lane allocation according to the node volume . . . . . . . . . . . . . . . . . . . . . . .
Illustration 265: Isochrone view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 266: Signal time-space diagram in mode "Flowing off" . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 267: Signal time-space diagram in mode "Arterial bands" . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 268: Column charts for time intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 269: Column chart for relations between network objects . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 270: Tabular timetable in the standard view. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 271: Tabular timetable in regular service mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 272: Table background classified by revenue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 273: Graphical timetable with classified display of vehicle journey line style properties . . .
Illustration 274: Item bars for vehicle journeys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Illustration 275: Classification of item bars with the vehicle journey volume . . . . . . . . . . . . . . . . . . . . .
Illustration 276: Display of item bars for boarding passengers, through passengers and alighting passengers

778

709
711
712
713
714
715
716
717
718
719
720
721
721
722
725
728
731
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
751
753
758
758
759
760
761
762
763
764
765
766
767

PTV AG

List of tables
Table 1: Additional attributes for a compared numerical attribute after version comparison . . . . . . . . . . 11
Table 2: Definition of scenarios based on modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Table 3: Extension of scenarios for a demand variant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Table 4: Basic network objects of a transport network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Table 5: PuT network objects of a transport network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Table 6: General network objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Table 7: PrT transport systems properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Table 8: Flow hierarchy symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Table 9: OD pairs in the example Example.ver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Table 10: Example of three vehicle journeys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Table 11: Input data for the calculation example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Table 12: Calculation of indicators for the line route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Table 13: Calculation of indicators for the links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Table 14: Network objects of the junction model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Table 15: Deriving projection factors for AP and AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Table 16: Example of the interaction of analysis time intervals and time series . . . . . . . . . . . . . . . . . . . 90
Table 17: Examples of input and output attributes at the link. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Table 18: Example of a 1..1 relation in the Visum network model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Table 19: Example of a 0..1 relation in the Visum network model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Table 20: Example of a 0..n relation with aggregate function Count . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Table 21: Example of a 0..n relation with aggregate function Min . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Table 22: Example of a 0..n relation with aggregate function Max. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Table 23: Example of a 0..n relation with aggregate function Sum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Table 24: Example of a 0..n relation with aggregate function Avg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Table 25: Example of a 0..n relation with aggregate function Concatenate . . . . . . . . . . . . . . . . . . . . . . 100
Table 26: Example of a 0..n relation with aggregate function Histogram . . . . . . . . . . . . . . . . . . . . . . . . 101
Table 27: Saving the cost per kilometer to a user-defined attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Table 28: Time-varying attributes and their allocation to assignment procedures . . . . . . . . . . . . . . . . . 105
Table 29: Impact of time-varying attributes in the Dynamic Stochastic assignment. . . . . . . . . . . . . . . . 106
Table 30: Table Main nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Table 31: Table Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Table 32: Table Surface items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Table 33: Table Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Table 34: Table Face items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Table 35: Table Edges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Table 36: Table Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Table 37: Table Intermediate points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Table 38: Examples of the normalization of surfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Table 39: Typical break-down of a demand stratum into 8 activities and 17 demand strata = activity pairs. 136
Table 40: Examples of relevant structural properties and person groups of the demand strata . . . . . . 137
Table 41: Trip generation in EVA model: OD type 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Table 42: Trip generation in EVA model: OD type 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Table 43: Trip generation in EVA model: OD type 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Table 44: List of the activity chains: mobility rates per person group in % . . . . . . . . . . . . . . . . . . . . . . . 163

PTV AG

779

List of tables

Table 45: Basic matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Table 46: Result matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 47: Abbreviations used in the User model PrT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 48: Example network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 49: Link-based PrT paths of a PrT assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 50: Variables used in VD functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 51: Parameters for all VD functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 52: VD function type BPR2: modified BPR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 53: VD function type BPR3: modified BPR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 54: VD function type CONICAL (Spiess) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 55: VD function type CONICAL_MARGINAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 56: VD function type EXPONENTIAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 57: VD function type INRETS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 58: VD function types LOGISTIC, QUADRATIC, SIGMOIDAL_MMF_NODES,
SIGMOIDAL_MMF_LINKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 59: VD function type AKCELIK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 60: VD function type AKCELIK2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 61: VD function type LOHSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 62: VD function type Linear Bottleneck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 63: Input data of the calculation of the link impedance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 64: Car travel times and speeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 65: HGV travel times and speeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 66: Calculation of link impedance for HGV and car. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 67: Advantages and disadvantages of the node impedance model . . . . . . . . . . . . . . . . . . . . . .
Table 68: Attributes for the impedance calculation from Turns VD function . . . . . . . . . . . . . . . . . . . . .
Table 69: Attributes for the impedance calculation from Node VD function . . . . . . . . . . . . . . . . . . . . .
Table 70: Attributes for the calculation regarding uncontrolled nodes. . . . . . . . . . . . . . . . . . . . . . . . . .
Table 71: Input attributes for signalized nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 72: Output attributes for signalized nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 73: Input attributes for the calculation of two-way stops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 74: Ranking of movements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 75: Calculation of the conflicting volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 76: Base values for the critical gap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 77: Follow-up times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 78: Impeding movements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 79: Allocation of a LOS to the mean delay per vehicle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 80: Input attributes for an All-Way stop node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 81: Adjustment factors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 82: Probability states calculation of degree-of-conflicts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 83: Excerpt from the DOC table for two lanes per approach. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 84: Lookup table base follow-up time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 85: Base values for the saturation follow-up time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 86: Determining the LOS based on the mean delay per vehicle . . . . . . . . . . . . . . . . . . . . . . . . .
Table 87: Input attributes for roundabout nodes according to HCM 2010. . . . . . . . . . . . . . . . . . . . . . .
Table 88: LOS per lane based on the mean delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 89: Input attributes for calculation according to the TRL/Kimber method . . . . . . . . . . . . . . . . . .
Table 90: LOS for calculation according to Kimber based on the mean delay . . . . . . . . . . . . . . . . . . .
Table 91: Input attributes with effect at signal coordination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

780

189
189
213
214
215
219
219
220
220
220
221
221
221
222
223
223
223
224
224
225
225
225
226
228
228
230
232
234
251
252
253
254
255
256
259
261
262
263
263
265
265
267
268
272
274
277
288

PTV AG

List of tables

Table 92: Output attributes of links for signal coordination results . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Table 93: Procedure parameters for signal coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 94: PrT skims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 95: Aggregation functions for the skim data calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 96: Parameters for the distribution with variable beta in illustration 91 . . . . . . . . . . . . . . . . . . . .
Table 97: Distribution for two alternatives with impedance 5 and 10 . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 98: Distribution for two alternatives with impedance 105 and 110 . . . . . . . . . . . . . . . . . . . . . . . .
Table 99: Distribution for two alternatives with impedance 50 and 100 . . . . . . . . . . . . . . . . . . . . . . . . .
Table 100: Model parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 101: Example of the incremental assignment (BPR function a=1, b=2, R=tCur) . . . . . . . . . . . . .
Table 102: Input attributes for the incremental assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 103: Output attributes of the incremental assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 104: Calculation of the user optimum for the example network . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 105: Calculation of the system optimum for the example network . . . . . . . . . . . . . . . . . . . . . . . .
Table 106: Example network for the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 107: Assignment results for the three PrT paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 108: Assignment result at the links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 109: Input attributes of the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 110: Output attributes of the equilibrium assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 111: Example equilibrium procedure (BPR function a=1, b=2) . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 112: Variants of route volumes for the link volumes in illustration 100. . . . . . . . . . . . . . . . . . . . .
Table 113: Variants of route volumes for the link volumes in illustration 101. . . . . . . . . . . . . . . . . . . . .
Table 114: Impedance in unloaded network, input parameters of Equilibrium_Lohse method . . . . . . .
Table 115: Example of Equilibrium_Lohse: 1st iteration step. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 116: Example of Equilibrium_Lohse: 2nd iteration step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 117: Example of Equilibrium_Lohse: 3rd iteration step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 118: Input attributes of the Equilibrium_Lohse procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 119: Output attributes of the Equilibrium_Lohse procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 120: Input attributes of the assignment with ICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 121: Additionally calculated turn/main turn attributes for assignment with ICA . . . . . . . . . . . . . .
Table 122: Additionally calculated link attributes for assignment with ICA. . . . . . . . . . . . . . . . . . . . . . .
Table 123: Input attributes for the stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 124: Output attributes for the stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 125: Impedance in the unloaded network, input parameters for stochastic assignment . . . . . . .
Table 126: Calculation of the commonality factor C for all route pairs . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 127: Volumes in the first internal iteration step m = 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 128: Volumes in the second internal iteration step m = 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 129: Input attributes for TRIBUT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 130: Output attributes for TRIBUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 131: Toll amounts for the example network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 132: Comparison of conventional toll assignment and TRIBUT . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 133: Input attributes for the DUE procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 134: Example of the Dynamic user equilibrium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 135: Output attributes of the Dynamic user equilibrium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 136: Input attributes of the dynamic stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 137: Output attributes of the dynamic stochastic assignment . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 138: Calculation rules for the output attributes of the assignment analysis . . . . . . . . . . . . . . . . .
Table 139: Demand matrix and temporal distribution of demand for the example . . . . . . . . . . . . . . . . .

288
289
290
290
313
315
315
315
315
317
319
320
321
321
323
323
324
325
326
330
344
345
346
347
348
349
351
352
358
359
359
366
367
373
374
374
375
377
378
382
383
413
417
418
422
423
427
432

PTV AG

781

List of tables

Table 140: PuT supply of the example with connections from A-Village to X-City . . . . . . . . . . . . . . . .
Table 141: Path legs after a timetable-based assignment (paths saved as connections). . . . . . . . . . .
Table 142: Path legs after a timetable-based assignment (paths saved as routes) . . . . . . . . . . . . . . .
Table 143: Skims of time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 144: Skims of length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 145: Monetary skims [Currency units] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 146: Skims of frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 147: Skims of attribute data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 148: Derived skims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 149: Example of the connection skims of an OD pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 150: Availability of the skims in the PuT assignment procedures . . . . . . . . . . . . . . . . . . . . . . . .
Table 151: Combination of skim data to the mean skim value per OD pair . . . . . . . . . . . . . . . . . . . . .
Table 152: Example for the determination of the time difference DT . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 153: Comparison of the impedance functions in the PuT assignments. . . . . . . . . . . . . . . . . . . .
Table 154: Connector weights for the example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 155: Temporary demand matrix for the assignment in the example . . . . . . . . . . . . . . . . . . . . . .
Table 156: Example for headway calculation from mean headway according to timetable . . . . . . . . .
Table 157: Example for headway calculation from mean wait time according to timetable . . . . . . . . .
Table 158: Considering elapsed wait time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 159: Travel times and headways of the lines in the example network . . . . . . . . . . . . . . . . . . . .
Table 160: Line shares and the mean costs depending on the information available. . . . . . . . . . . . . .
Table 161: Headway calculation for the example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 162: Impedance calculation for the routes in the example . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 163: Changes to shares with variation of the transfer penalty. . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 164: Mean skim values for the headway-based assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 165: Calculation of the temporal distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 166: Procedure parameters for the comparison of the distribution models . . . . . . . . . . . . . . . . .
Table 167: Example 1 Initial situation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 168: Example 2 Isochronous, identical pair of connections . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 169: Example 3 Identical pair of connections with high temporal proximity . . . . . . . . . . . . . . .
Table 170: Example 4 Similar pair of connections with high temporal proximity (connection 3 now
includes transfer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 171: Example 5 - Differing pair of connections with moderate temporal proximity . . . . . . . . . . .
Table 172: Result of connection search (transfer penalty 10 min, parameter file timetab1.par) . . . . . .
Table 173: Temporal distances T and impedances R of the connections for the two analyzed
intervals of travel demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 174: Distribution of trips to the connections (Kirchhoff, = 3). . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 175: Calculation rules for the output attributes of the assignment analysis. . . . . . . . . . . . . . . . .
Table 176: Status indicators for the surveyed path leg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 177: Status indicators for the preceding section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 178: Status indicators for the succeeding section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 179: Status indicators for the entire survey data record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 180: Level Territory x Transport system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 181: Indicators for line route analysis by territory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 182: Territory-based indicator data for transport performance and revenue analysis . . . . . . . . .
Table 183: Territory-based analysis on aggregation level Territory x Line . . . . . . . . . . . . . . . . . . . . . .
Table 184: Analysis of the Vol/Cap ratio of seats on the line route level. . . . . . . . . . . . . . . . . . . . . . . .
Table 185: Service kilometer analysis on the level of lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 186: Cost and revenue computation on the level of lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
782

433
435
436
437
439
439
440
440
440
442
443
445
447
448
449
449
455
455
463
469
470
471
472
473
473
484
487
487
488
488
488
488
489
490
490
508
517
517
518
518
523
524
525
526
527
527
528

PTV AG

List of tables

Table 187: Evaluation of transport performance indicators on the level of operators . . . . . . . . . . . . . .


Table 188: Evaluation of service kilometers per time interval for the bus operator . . . . . . . . . . . . . . . .
Table 189: PassengerKm-to-ServiceKm ratio for the Bus operator . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 190: Example line block with pull-out trip, interlining trip and pull-in trip . . . . . . . . . . . . . . . . . . .
Table 191: Block data of the three approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 192: Block items of the line blocks in block version 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 193: Block items of the line blocks in block version 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 194: Block items of the line blocks in block version 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 195: Open block and closed block for the unsymmetrical example (illustration 177) . . . . . . . . . .
Table 196: 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. . . . . . . . . . . . . . . . . . . . . . . .
Table 197: Block version attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 198: Block attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 199: Block item attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 200: Block item type attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 201: Attributes of the line blocking cost function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 202: Depot attributes of stop points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 203: Cost rates for downtimes at depots and stop points at vehicle unit (cost rates in
table 201 refer to this) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 204: Cost rates for downtimes at depots and stop points at the vehicle combination (cost rates
in table 201 refer to this) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 205: Turn standard attributes with reference to running directions . . . . . . . . . . . . . . . . . . . . . . .
Table 206: Turn attributes with reference to running directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 207: Line route attributes with reference to running directions. . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 208: Objective function components for line blocking with vehicle interchange . . . . . . . . . . . . .
Table 209: Line blocking and vehicle requirement indicators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 210: Example illustrating different variants of distribution of empty time and empty kilometers
on individual vehicle journeys.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 211: PuT interlining matrix with t-PuTSys between stop points . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 212: Linking fare systems and demand segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 213: Transport supply in Example_LLE.ver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 214: Projection factors for the valid days in Example_LLE.ver . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 215: Projection factor for the demand segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 216: Total capacity provided in the vehicles of example Example_LLE.ver. . . . . . . . . . . . . . . . .
Table 217: Fare model in Example_LLE.ver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 218: Fares of the fare model in Example_LLE.ver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 219: Transport demand between the zones in Example_LLE.ver . . . . . . . . . . . . . . . . . . . . . . . .
Table 220: Cost rates for vehicles in Example_LLE.ver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 221: Indicators for line route and timetable evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 222: Indicators of the transport supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 223: Indicators of the network performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 224: Vehicle type-dependent costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 225: Infrastructure costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 226: Total cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 227: Cost rates for the vehicle units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 228: Cost rates for the vehicle combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 229: Distances and times for the vehicle combination Train in the analysis period . . . . . . . . . . .
Table 230: Formulas for calculating link costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 231: Example calculation for link depreciation costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

529
529
530
534
538
539
541
543
546

PTV AG

783

546
548
549
552
553
554
555
556
556
559
559
559
576
580
581
582
595
606
607
607
607
607
608
608
608
609
615
618
624
624
624
625
626
626
627
627

List of tables

Table 232: Example calculation for running costs of links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Table 233: Example calculation for link utilization costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 234: Formulas for the calculation of stop point costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 235: Formulas for calculating operator costs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 236: Calculation example for depreciation costs of the operator. . . . . . . . . . . . . . . . . . . . . . . . .
Table 237: Calculation example for the running costs of the operator . . . . . . . . . . . . . . . . . . . . . . . . .
Table 238: Revenue indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 239: Revenue share per path leg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 240: Revenue per line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 241: Revenue share per path leg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 242: Revenue per line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 243: Calculation of the revenues per path (PuT routes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 244: Revenue calculation for the path leg Bus1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 245: Aggregation of the path leg revenues to lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 246: Input data for the calculation example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 247: Revenue distribution W-NumFP = 1.0, W-NumPL= 0.0, FixSuppl = 0 . . . . . . . . . . . . . . . .
Table 248: Revenue distribution W-NumFP = 0.5, W-NumPL = 0.5, FixSuppl = 0.00 . . . . . . . . . . . . .
Table 249: Revenue distribution W-NumFP = 0.5, W-NumPL = 0.5, FixSuppl = 0.20 . . . . . . . . . . . . .
Table 250: Indicators for the cost coverage calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 251: Cost coverage calculation from revenues and costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 252: Which projection factor applies for the calculation of indicators? . . . . . . . . . . . . . . . . . . . .
Table 253: Difference in the projection to AH for ServiceKm and PassengerKm . . . . . . . . . . . . . . . . .
Table 254: Further specifications for the vehicle journey with two VJ sections. . . . . . . . . . . . . . . . . . .
Table 255: Calculation of seat kilometers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 256: Calculation of service kilometers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 257: Link attributes for noise calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 258: Pollutant-Emis link attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 259: EWS-specific link attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 260: Reading shape files in Visum network objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 261: Illustration of Visum files of shape types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 262: Calculating the number of PuT passengers per zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 263: Calculating the number of inhabitants in the catchment areas of lines . . . . . . . . . . . . . . . .
Table 264: Calculating the number of inhabitants in the catchment areas of stops . . . . . . . . . . . . . . .
Table 265: Calculating the vehicle kilometers within territories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 266: Calculating the zone number where a stop point lies . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 267: Determination of the numbers of the stops that lie within a zone . . . . . . . . . . . . . . . . . . . .
Table 268: Calculating the average number of PuT passengers at the stops of a zone . . . . . . . . . . . .
Table 269: Available aggregate functions for intersection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 270: Planar coordinate system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 271: Geographic coordinate system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 272: Background formats supported by Visum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 273: Example for a World file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 274: Traffic type based on status (active / passive) of links or PuT lines . . . . . . . . . . . . . . . . . .
Table 275: Significance of traffic types after applying path filter for active PuT lines . . . . . . . . . . . . . .
Table 276: Territory lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 277: Stop lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 278: Item lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table 279: Line lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

784

628
628
629
630
631
631
632
633
634
634
635
636
637
638
639
639
639
639
640
641
641
642
643
644
644
652
656
666
673
676
678
679
679
680
680
681
681
682
687
687
693
694
703
705
729
730
730
730

PTV AG

List of tables

Table 280: Line block lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731


Table 281: Evaluation lists for paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
Table 282: Statistical evaluation lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732

PTV AG

785

List of tables

786

PTV AG

Index

Index
A
Activities 5, 122
attributes (EVA) 132
Activity chains 123, 161, 163
Activity pairs 5, 123
attributes (EVA) 132
Adding complex terms 188
Air pollution emissions 654
Akcelik (VD function) 223
Analysis
analysis horizon 89
analysis period 88
analysis time intervals 89, 92
analysis time slots 88
Annual calendar 85
Assessment types 153
Assignment analysis
PrT 426
PuT 506
Assignment procedure
see Assignments
Assignment quality 307
Assignment time interval 88
Assignments
demand segments 37
distribution models 308
PrT procedures
see PrT assignment procedures
PuT procedures
see PuT assignment procedures
Attraction 128, 135, 139, 151
Attributes
direct 94
indirect 95
time-varying 105
user-defined 101
Average Excess Cost AEC (PrT assignment quality) 308

B
Background formats 693
Backgrounds 689
automatic positioning 694

PTV AG

by Bing Maps 691


dynamically embed
from the Internet 690
statically embed
from the Internet 690
Bar display 8, 733
Best-route assignment 316
Bing Maps 691
Block item types 552
Block items 552
Block version 547
Blocking back model 292
Blocks 549
Bounding 479
Box-Cox model 310
BPR (VD function) 220
Branch and Bound 478
Buffer 681

C
Calculate skim matrix (procedure) 290
Calculation results
temporal distinction 92, 93
Calendar 57, 84
Calendar period 88
Capacities
adjusting to demand values 93
Cascetta 370
Charts 8
column charts 742, 759
pie charts 743
Choice models
with independence 487
C-Logit approach 370
Cold start excess emissions
calculation according to HBEFA 660
Column charts 8, 759
Commonality factor 370
Conical (VD function) 220
Conical marginal (VD function) 221
Connection 478
Connection choice
timetable-based assignment 484

787

Index

Connection search 478


Connections
independence (timetable-based assignment) 485
skims 437
Connectors 46
demand distribution
PuT 448
destination connector 46
distributing transport demand
PrT 47, 291
PuT 47
distribution of demand 47, 291
impedances 217
Multi Point Assignment (MPA) 47, 291
origin connector 46
Constant from time profile attribute (headway calculation) 454
Constraints 139, 162
Control types at node 229
Coordinate systems 686
Coordination groups 474
Cordon links 49
Cost (PuT) 622
Cost-benefit analysis 663, 669
Cost-benefit ratio (CBR) 665
Count locations 74
Coupling time profiles 67
Crosswalks 81
Cycle time optimization 277

Demand objects 5, 119


Demand segments 34, 36, 120
Demand strata 5, 124
attraction 128, 135, 139, 151
attributes (EVA) 133
home trips 151, 164
production 128, 135, 139, 151
Desire lines 744
Detectors 74
Direct assignment 519
Display
2D 752
Displaying transfer flows 749
Displaying turn volumes 743
Distribution models 308
Box-Cox model 310
Kirchhoff model 309
Logit model 309
Lohse model 311
with variable beta 312
DMRB guideline TD 16/93 (roundabouts) 273
Dominance 479
DUE 389
Dynamic stochastic assignment 419
input and output attributes 422
procedure 423
Dynamic User Equilibrium (DUE) 389
evaluation 389
input and output attributes 412

DeltaT 483
early 483
late 483
Demand
distribution to PuT connectors 448
see Transport demand
Demand matrices 3, 120
updating 195
Demand model 119
Demand model structure 121
Demand models 1, 3
activity chain based
see Demand models, Tour-based model
EVA model for passenger demand 5, 132
Standard 4-step model 5, 126
time series 5
Tour-based model 5, 161

Economic assessment 663


Edge 111
Environmental impact model 651
air pollution emissions 654
noise volume 651
Pollution-Emis procedure 654
Equilibrium assignment 320
evaluation 321
examples 322, 330
input and output attributes 324
procedure 326
Equilibrium_Lohse 346
evaluation 354
examples 346
input and output attributes 350
procedure 353
E-ticketing 513

788

PTV AG

Index

EVA
see EVA model for passenger demand
EVA model for passenger demand 5, 119, 132
activities 132
activity pairs 132
assessment types 153
balance factors 158, 161
balancing 143
constraints 139
demand strata 133
elasticity functions 155
evaluation 153
evaluation functions 152, 154
weighting probabilities 153
Furness method
trilinear 158
home trips 151
mobility rates 138
mode choice 152
multi procedure
trilinear 158
structural properties 132
study area factors 138
trip distribution 152
trip generation 135
zones 134
EWS-97 663

F
Face items 111
Faces 111
Fares 447
Flow bundles 7, 697
alternative routes 711
combining flow bundle criteria 706
defining flow bundles 699
displaying paths 711
link flow bundles 701
main node flow bundles 700
node flow bundles 699
selecting network objects 699
selecting types of traffic 701
stop point, stop area, and stop flow bundles 701
zone and main zone flow bundles 701

G
Gap (PrT assignment quality) 308
Geographic information systems (GIS) 671

PTV AG

Georeferencing 686
GIS objects 76, 671
Go to procedure (procedure) 4, 182, 183, 184
GPS tracking 695
Graphic objects 688
Graphical display 725
Graphical timetable 763
Gravity model 129, 174
calculating 174
calibrating 173
Green time optimization 277, 279

H
HBEFA
basis for calculating cold start excess emissions 660
basis for calculating warm emissions 658
emission calculation 657
HBEFA-based emission calculation 657
HCM 229
Headway calculation
from mean headway 454
from mean wait time 455
Headway-based assignment 453
coordination 474
generalized costs 456
headway calculation 454
impedance 456
Highway Capacity Manual (HCM) 229
Histogram 186
Home trips 151, 164
Hypothetic vehicle impedance (PrT assignment
quality) 308

I
ICA 229
Impact models 1, 6, 205
Environmental impact model 207
Operator model 206
User model 205
Impedance functions 207
at node 226
EVA model for passenger demand 153
headway-based assignment 456
PrT assignments 216
timetable-based assignment 481
Impedances
connectors 217

789

Index

examples 224
headway-based assignment 456
links 217
main turns 218
nodes 217
preloaded volume 218
routes 216
turns 217
Incremental assignment 315
evaluation 320
examples 316
input and output attributes 318
procedure 317
Independence of connections 485
Indicators 209
aggregation along line hierarchy 645
calculating aggregation levels 522
calculation for coupled sections 647
calculation for partially traversed links 647
calculation principles 641
examples 523, 526, 529
global indicators 210
projection of additional attributes 648
projection to analysis horizon 641
temporal dependencies (example) 642
territory-based cut 646
territory-based evaluation (aggregation levels) 525
time cut 646
Indirect attributes
aggregation functions 96
Average and AverageActive 99
Concatenate and ConcatenateActive 99
Count and CountActive 96
Frequency and FrequencyActive 100
Max and MaxActive 98
Min and MinActive 97
relations 95
Sum and SumActive 98
INRETS (VD function) 222
Interactive analyses 697
flow bundles 697
isochrones 713
shortest path search 722
Intermediate points 111
Intersection Capacity Analysis (ICA) 229
all-way stop 260
roundabouts 267
signalized nodes 230

790

two-way stop nodes 250


uncontrolled nodes 230
Isochrones 7, 713
combining PrT and PuT isochrones 720
PrT isochrones 715
PuT isochrones 717

J
Journey sections 62
Journeys 61
Junction
traffic-related modeling 78
Junction model 78
signal control 82
Junction modeling 78

K
Kirchhoff model 309

L
Lanes 81
lane allocation 750
lane turns 81
Leg templates 82
Legend 688
Legs 80
Level of Service 259
Line block check 560
common 562
forced 562
Line blocking 532, 533
block item and block item type 552
block version 547
blocks 549
cost function 554
coverage check 563
data model 536
depots 555
distributing empty trips and empty times 579
evaluation of the procedure 535
examples 536
layover times 555
line block check 560
lists 730
optimization problem 534
procedure description 564
PuT interlining matrix 579
with vehicle interchange

PTV AG

Index

procedure description 573


without vehicle interchange 563
Line hierarchy 57
data consistency 66
Line routes 58
aggregating 66
editing shape with system routes 71
specifying lengths 63
Linear bottle-neck (VD function) 224
Lines 58
Link orientations 79
Links 40
impedances 217
link types 41
major flows 41
permitted transport systems 42
PrT capacity 43
PrT speed 43
PrT travel time 43
PuT run time 44
specifying lengths 63
specifying link run time 63
Lists 8, 726
assignment analysis 733
coupling section items 730
coupling sections 730
emissions HBEFA 733
item lists 730
line blocks 731
line block items 731
line block lists 730
line block versions 731
line lists 730
line route items 730
network information 732
OD pair lists 729
PrT
assignment quality 733
path sets 731
paths 731
paths on link level 732
quality assignment with ICA 733
PuT
assignment statistics 733
detail list 729
OD pairs 732
path legs 732
paths 732

PTV AG

PuT assignment statistics 733


shortest path search 732
stop lists 729
stop points - arrivals/departures 730
stop transfers and stop area walk times 730
system route items 730
territory lists 728
time profile items 730
time profiles
transition walk times 730
transfers 732
transport systems
transition walk times 730
vehicle journey items 730
Logit model (Distribution model) 309
Lohse (VD function) 224
Lohse model 311
with variable beta 312

M
Main lines 58
Main nodes 48
Main relations 51
Main turns 50
impedances 218
Main zone matrices
disaggregating 191
Main zones 51
Major flows 41
Matched transfers 475
Matrices 3, 120
adding columns or rows 191
adding complex term 188
aggregating 192
calibrating (PrT) 203
classifying matrix values 186
combining matrices and vectors 188
correcting 195
demand matrices 120
diagonal
extracting 187
setting 187
editing 184
functions 184
exponential function 187
extending 191
see Matrices, splitting
forming maximum or minimum 187

791

Index

forming reciprocal 187


gravity model
calculating 174
calibrating 173
logarithmic 187
making symmetric 188
mean value upper/lower triangle 188
projecting 188
projecting path volumes (PrT) 202
projection of aggregated areas 190
raising to power 187
reflecting 187
skim matrices 120
splitting 194
transposing 186
weighting matrices 160
Matrix correction 195
calibrating matrix (PrT) 203
projecting path volumes (PrT) 202
TFlowFuzzy 195
Matrix editor 5, 120, 184
Mean value
calculating
attributes 184
matrices 183
Merge network 15
Method of Successive Averages 183, 184
Mode choice 4
EVA model for passenger demand 152
nested (Standard 4-step model) 127, 130
Standard 4-step model 130
Tour-based model 168
Model transfer files 17
Models
comparing 8
Modes 34, 36
MPA
see Multi Point Assignment
MSA
see Method of Successive Averages
Multi Point Assignment 47, 291
Multi procedure 174, 176, 189
trilinear (EVA) 158

N
NCHRP 255 425
Nested Mode Choice
see Mode choice, nested

792

Network check 84
Network display
bars 733
classified 736
labeling with charts 741
labeling with tables 740
Network merge 14
analysis time intervals 17
examples 14
Network model 1, 2
Network objects
block 549
block item 552
block item type 552
block item types 33
block version 547
block versions 33
buffer 681
connectors 30, 46
count locations 33, 74
demand segments 29, 34, 36, 120
detectors 34, 74
fare zones 33
GIS objects 34, 76, 671
intersecting 677, 681
line blocking 536
line routes 32, 58
lines 32, 58
link types 30
links 30, 40
main lines 32, 58
main nodes 30, 48
main OD pairs 51
main turns 30, 50
main zones 30, 51
modes 29, 34, 36
nodes 29, 38
OD pairs 31
Operator model (PuT) 530
paths 31, 52
Points of Interest (POI) 33, 72
PuT coordination groups 33
PuT operators 32, 56
PuT vehicles 57
screenlines 34, 77
stop areas 31, 55
stop points 31, 54
stops 31, 56

PTV AG

Index

system routes 32, 70


territories 30, 52
ticket types 33
time profiles 32, 60
toll systems 34
transport systems 29, 34, 35
turn standards 30
turns 30, 38
valid days 31, 57, 85
vehicle combinations 32, 57
vehicle journey sections 32, 62
vehicle journeys 32, 61
vehicle units 33, 57
zones 30, 45
Networks
comparing 8
Node geometry 80
crosswalks 81
lane turns 81
lanes 81
leg templates 82
link orientations 79
node legs 80
node templates 82
Node impedances 226
calculate according to HCM 229
nodes VD function (TModel) 228
turns VD function 228
Node templates 82
Node topology 80
graphically displaying 750
Nodes 38
control types 229
impedances 217, 226
signal control 82
signal time optimization 277
Nodes VD function (TModel) 228
Noise volume 651
Noise-Emis-Nordic procedure 651, 652
Noise-Emis-Rls90 procedure 651
Normalizing 114

O
OD matrices
see Demand matrices
OD pairs 46
Operator model 530
Operator model (PuT) 206, 521

PTV AG

examples 523, 526, 529


indicators (aggregation levels) 522
line blocking 532
network objects 530
territory-based evaluation (aggregation levels) 525
work flow 531
Operators
in the operator model 530
Optimizing cycle and green time 278, 281
Optimizing offset times 281
Origin wait time (Timetable-based assignment) 482

P
Passenger survey 509
direct assignment 519
survey data
assignment 519
plausibilization 513
reading 513
Path legs
PrT 215
PuT 434
Paths 52, 209
displaying (flow bundles) 711
filtering (flow bundles) 697
PrT 215
PuT 434
Perceived journey time 446, 481
Person groups 5, 122
Personal Geodatabase (PGD) 671
Point 111
Points of Interest (POI) 72
Pollution-Emis procedure 654
Polygons 111, 694
Procedure description
line blocking without vehicle interchange 563
Production 128, 135, 139, 151
Projecting path volumes (PrT) 202
Projection 88
examples 90
Projections 686
PrT
path legs 215
path objects 52
paths 215
PrT assignment procedures 211
convergence criteria 307
dynamic stochastic assignment 419

793

Index

Dynamic User Equilibrium 389


equilibrium assignment 320
Equilibrium_Lohse 346
impedance functions 216
incremental assignment 315
stochastic assignment 365
toll 376
TRIBUT 376
use solution as initial solution 218
VD functions 218
PuT
Aux transport systems 491
operating indicators 581
cost and revenue model 622
cost per hour 625
distributing empty trips and empty times 579
examples 605, 631
kilometer costs 625
line route and timetable analysis 609
link costs 626, 627
network performance measurement 618
operating cost 622, 623
operator costs 629
revenue calculation 632
stop point costs 628
transport supply measurement 615
vehicle costs 625
vehicle type costs 624, 625
Operator model 7, 530
operators 56, 530
passenger surveys 509
path legs 434
paths 434
revenues 632
calculate using fare model 636
distribute across PuT path legs 636
fixed revenue per PTripUnlinked 633
fixed revenue per traversed fare point 634
vehicles 57
PuT assignment procedures 429
headway-based 453
timetable-based 477
TSys-based 450
PuT connections and transfer flows 749
PuT interlining matrix 579
PuT revenues
cost coverage calculation 640
PuT transfer relations 748

794

Q
Queues 221

R
Ramp metering 221
RAS-W-86 663
Result analysis 7
Revenues (PuT) 622
fares 447
RLS-90 651
Route loading
TSys-based assignment 453
Route search
TSys-based assignment 452
Routes
distribution of demand 308
impedances 216
skims 437

S
Scenario management 18
Scenarios 18
calculating 23
creating based on modifications 23
defining modifications 22
distributed calculation 24
Schematic 754
Schematic line diagrams 754
displaying demand and transfer flows 756
displaying supply 754
editing 754
transferring the layout 756
Screenlines 77
Shape files 672
Shortest path search 7, 480, 722
PrT 7, 722
PuT 7, 723
Signal control 82
stage templates 84
Signal controls
optimizing cycle and green time 278, 281
optimizing offset times 281
Signal coordination 278, 281
Signal time optimization 277
Signal time-space diagram 757
Skim matrices 7, 120
Skims 209
calculating (PrT) 290

PTV AG

Index

PuT 437, 439, 440


skim matrices 209
Standard 4-step model 5, 119, 126
mode choice 130
nested 127, 130
time-of-day choice 131
trip distribution 129
trip generation 128
Stochastic assignment 365
commonality factor 370
distribution models 308
evaluation 365
examples 373
Stop points 54
Stops 56
displaying catchment areas 746
hierarchies 54
stop areas 55
Structural properties 128
EVA model for passenger demand 132
tour-based model 161
Subnetwork generator 107
Surface items 111
Surface model 111
multi-part surface 114
normalizing surfaces 114
tables 111
Surfaces 111
Survey data
assignment 519
plausibilization 513
reading 513
System optimum 221, 321
System routes 70

T
Tables 8
Tabular display 725
Tabular timetable 760
tCur 218
Temporal utility 447
Territories 52, 93
Texts 688
TFlowFuzzy 195
Time profiles 60
coupling 67
specifying run times 63
Time series 86, 121

PTV AG

examples 90
matrix numbers 5, 87, 121
percentage 5, 87, 121
Time-of-Day Choice
Standard 4-step model 131
Timetable editor 8, 760
evaluations 760
graphical timetable 763
tabular timetable 760
Timetable-based assignment 477
connection choice 484, 489
connection preselection 481
connection search 478
Branch and Bound 478
shortest path search 480
distribution of trips over connections 484
evaluation 477
fare 484
impedance 481
independence of connections 485
opening 492
perceived journey time 481
PuT-Aux TSys 491
temporal utility 447
temporal utility of a connection 483
Timetables 65
Time-varying attributes 105
TModel 228
Toll in the assignment 376
Toll systems 75
Total Excess Cost TEC (PrT assignment quality) 308
Tour-based model 5, 119, 161
activity chain based model 161
constraints 162
destination choice 164
home trips 164
mode choice
combined 168
structural properties 161
trip distribution
combined 164
trip generation 163
utility function 165, 168
Transfer relations 748
Transfer wait time (Timetable-based assignment) 482
Transport demand 1, 3, 4, 119
distributing to PrT connectors 291
distributing to routes 308

795

Index

model 1, 3, 125
time reference 86
time series 86
Transport demand matrices
see Demand matrices
Transport demand model 1, 3
Transport system-based assignment 450
Transport systems 34, 35
TRIBUT procedure 376
Trip distribution 4
EVA model for passenger demand 152
Standard 4-step model 129
Tour-based model 164
Trip generation 4
EVA model for passenger demand 135
Standard 4-step model 128
Tour-based model 163
TSys-based assignment
evaluation 451, 452
route loading 453
Turn volumes display 7
Turns 38
impedances 217
PrT capacity 40
PrT turn time 40
turn standards 39
turn types 39
Turns VD function 228

U
User models 6
User optimum 221, 321
User-defined attributes 101

V
Valid days 57, 85
Value of time (VT) 378
VD functions 218
Akcelik 223
BPR (according to Traffic Assignment Manual) 220
conical 220
conical marginal 221
INRETS 222
linear bottle-neck 224
logistic 222
Lohse 224
quadratic 222

796

SIGMOIDAL_MMF_LINKS 222
SIGMOIDAL_MMF_NODES 222
user-defined 225
Vehicle combination set 573
Vehicle combinations 57
in the operator model 530
Vehicle journey sections 62
Vehicle journeys 61
Vehicle units 57
in the operator model 530
Version comparison 9
Versions
comparing 8

W
Weekly calendar 85
Weighting (EVA) 153, 160
evaluation functions 152, 154
Box-Cox 155
Box-Tukey 155
combined 155
EVA1 154
EVA2 154, 157
Kirchhoff 155
Logit 155
Schiller 155, 157
TModel 155
weighting matrices 160
weighting probabilities 153
Weighting matrices 120
World files 694

Z
Zone matrices
aggregating 191
Zones 45
attributes (EVA) 134

PTV AG

Index

PTV AG

797

PTV GROUP
Haid-und-Neu-Str. 15
76131 Karlsruhe
Germany
Telefon +49 (0) 721 96 51 300
Fax +49 (0) 721 96 51 562
E-Mail info@vision.ptvgroup.com
www.ptvgroup.com
www.vision-traffic.ptvgroup.com

You might also like